Mill构建工具中的间歇性代码缓存满问题分析与解决

在Mill构建工具升级到Scala 3后，开发者开始观察到间歇性出现的"CodeHeap 'non-profiled nmethods' is full"警告信息。这个问题会导致JIT编译器被禁用，严重影响构建性能。本文将从技术角度深入分析该问题的成因和解决方案。

问题现象

当执行Mill构建任务时，控制台会输出以下警告信息：

OpenJDK 64-Bit Server VM warning: CodeHeap 'non-profiled nmethods' is full. Compiler has been disabled.

同时伴随详细的代码堆使用情况统计，显示非性能分析代码堆(non-profiled nmethods)已接近满载。

问题根源

通过JProfiler堆内存分析工具，可以观察到每次执行构建任务时，java.net.URLClassLoader的实例数量都会增加约10个，这表明存在类加载器泄漏问题。

进一步分析堆内存引用关系发现：

1. 正常的类加载器通过RunnerState$Frame#workerCache引用
2. 泄漏的类加载器则通过RunnerState$Frame#evaluator保持引用

此外，Coursier的线程池通过DynamicVariable/InheritableThreadLocal机制也捕获并持有了某些资源，加剧了内存泄漏。

问题复现

开发者提供了几种复现方式：

1. 执行完整清理后重新编译：git clean xdf && ./mill __.compile
2. 执行特定测试套件：./mill libs.scalalib.test.testOnly后跟一系列测试类

解决方案

基于分析结果，修复方案应关注以下几个方面：

1. 修复RunnerState$Frame中evaluator对类加载器的引用泄漏
2. 检查并修复Coursier线程池的资源持有问题
3. 确保所有类加载器在使用后能被正确释放

技术启示

这个问题给我们的启示是：

1. 在构建工具这类长期运行的应用中，资源管理尤为重要
2. 类加载器泄漏是JVM应用中常见但难以发现的问题
3. 线程局部变量和继承式线程局部变量可能导致隐蔽的资源保持
4. 升级编译器版本时，需要特别关注内存管理相关的变化

通过解决这个问题，不仅修复了Mill构建工具的性能问题，也为类似JVM应用的资源管理提供了有价值的参考案例。