JIT编译器对控制台应用与Web API的代码优化为何存在差异？

我在Release模式下分别编译Web API和控制台应用的简单代码，得到了不同结果。

Web API代码：

var builder = WebApplication.CreateBuilder(args);

WeatherForecast _weatherForecast = new WeatherForecast();
_weatherForecast = null;

builder.Services.AddControllers();

控制台应用代码：

WeatherForecast weatherForecast = new WeatherForecast();
weatherForecast = null;

随后我使用ILSpy工具查看这些DLL，发现结果完全不同：控制台应用的JIT编译器移除了weatherForecast = null语句，而Web API中该语句保留。这是否意味着在控制台应用中手动将引用类型变量置null以提前辅助GC并无意义？

没错，在绝大多数控制台应用场景下，手动给引用类型变量置null来辅助GC确实没什么意义，你的观察已经能说明问题。

原因很简单：Release模式下的JIT编译器会做死代码消除优化。在控制台的那段代码里，weatherForecast变量在被赋值为null之后就再也没被用到过，编译器能识别出这行代码对程序运行结果没有任何影响，所以直接把它删掉了——既然代码都被优化掉了，自然不可能起到辅助GC的作用。

而Web API里那行_weatherForecast = null没被移除，大概率是因为这个变量的上下文和控制台里的不一样。比如ASP.NET Core的托管环境让JIT编译器的优化策略有所调整，或者变量后续存在编译器没检测到的间接引用（比如反射、异步上下文关联等），导致编译器不敢贸然删除这行代码。

但不管Web API的情况如何，对于普通控制台应用里的局部变量，你完全没必要手动置null。CLR的GC本身就会根据变量的实际使用情况判断对象是否可回收——当变量超出作用域，或者在代码里再也不会被访问时，GC就会把对应的对象标记为可回收，手动置null不仅帮不上忙，还会增加不必要的代码。

内容的提问来源于stack exchange，提问作者west