NLog中ObjectReflectionCache与MruCache内存占用问题咨询

很高兴能帮你解答NLog缓存相关的问题，结合NLog 4.7.2的实现细节，我来逐一说明你的疑问：

一、ObjectReflectionCache 和 MruCache 的作用 #

• ObjectReflectionCache：这是NLog内部用来缓存反射元数据的核心类。NLog在处理日志（比如解析布局渲染器、序列化日志对象属性）时，需要频繁通过反射获取类型信息、属性/方法的访问器。为了避免重复执行昂贵的反射操作，这个缓存会把这些反射结果存起来，后续直接复用，以此提升日志处理的性能——毕竟反射是出了名的耗时操作，缓存能帮你省下不少重复计算的时间。
• MruCache：也就是「最近最少使用缓存」，它是NLog实现的一种缓存淘汰策略。当缓存条目达到设定上限时，它会自动移除最久未被访问的条目，以此平衡内存占用和访问效率。你在dotMemory里看到的那个Dictionary，其实就是MruCache内部用来存储缓存项的底层容器。

二、Dictionary占用300k内存的原因 #

在NLog 4.7.2版本中，MruCache的默认容量设置不算小，再加上.NET的Dictionary本身会预分配一定的内存空间（避免频繁扩容），当NLog初始化时，会预加载不少默认布局渲染器、目标的反射信息，这些条目累加起来就会达到300k的占用。哪怕你的配置只用到了DebuggerTarget，NLog内部还是会初始化一些通用的组件，这些都会被缓存起来。

三、内存释放的时机 #

默认情况下，这两个缓存都是静态缓存，会一直驻留在内存中，直到你的WPF应用程序的AppDomain被卸载（也就是应用关闭的时候）。不过也有一些办法可以手动干预：

• 如果你在运行时确实需要释放这部分内存，可以尝试调用LogManager.Shutdown()（不过这会关闭NLog的日志功能，后续需要重新初始化）；
• 不建议直接通过反射去清理内部缓存，因为这是NLog的私有实现，后续版本可能会变动，容易引发问题；
• 更合理的方式是优化你的日志场景：如果你的日志不需要处理复杂对象、自定义渲染器，尽量简化NLog配置，减少需要反射的组件，缓存自然就不会那么大。

额外小建议 #

如果你的应用对内存占用比较敏感，不妨考虑升级到NLog 5.x及以上版本。新版本对内存管理做了不少优化，缓存策略更高效，默认的缓存容量也做了调整，能有效降低这类内存占用。

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