我来帮你梳理这个JVM编译的问题——你遇到的重复编译、non-reentrant转zombie的现象，结合AdoptJDK 11.0.7和音频处理的场景，其实是几个机制叠加的结果，咱们一步步拆解：

先搞懂你看到的现象本质 #

首先得明确JVM分层编译和这些状态的逻辑：

• 分层编译的正常流程：默认是Tier0（解释执行）→Tier3（C1轻量编译）→Tier4（C2重度优化编译），正常情况下同一方法不会在同一Tier反复编译。你遇到的Tier4版本循环编译、转zombie，肯定是某个触发条件打破了这个逻辑。
• Non-Reentrant与Zombie的意义：当JVM要重编译一个方法时，会先把当前版本标为non-reentrant——禁止新调用进入，等现有调用都退出后，这个版本就变成zombie（等待回收）。频繁出现这个情况，要么是编译依赖被破坏了，要么是JVM的编译触发逻辑在你的场景下误判了。
• 音频处理场景的特殊性：你的应用处理音频，大概率涉及JNI调用、动态生成字节码（比如解码库的动态代理、ASM生成的处理类）或者高频反射操作——这些操作都会让JVM的编译缓存失效，强制触发重复编译。

针对性排查与优化方案 #

1. 先定位重复编译的根源 #

要解决问题，得先知道哪些方法在反复编译，以及为什么：

• 添加上更详细的编译日志参数：-XX:+PrintCompilationDetails（JDK 11支持），它会告诉你编译触发的原因（比如“invocation counter overflow”调用次数超标，或者“dependency invalidated”编译依赖失效）。
• 配合-XX:+PrintInlining查看内联情况——如果某个方法因为内联失败反复触发重编译，也会出现你看到的现象。

2. 解决同一Tier的重复编译问题 #

如果日志显示是编译依赖失效导致的：

• 检查你的音频处理库是否有动态修改类结构的操作（比如用ByteBuddy、ASM在运行时修改方法），这类操作会直接让JVM的编译依赖作废，强制重编译。
• 排查是否有类加载器泄漏：每次运行任务时加载新的类实例，JVM会把它当成新方法处理，自然会反复编译（哪怕业务逻辑是同一个）。

如果是编译触发阈值的误判：

• 调整分层编译的触发阈值参数，比如：

  -XX:Tier3InvocationThreshold=10000  # 提高Tier3编译的触发阈值，减少轻量编译次数
  -XX:Tier4InvocationThreshold=100000 # 提高C2编译的触发阈值，避免频繁重编译
  

  注意：这些参数要根据你的业务场景调，太高会让首次运行变慢，太低会加重重复编译。

3. 优化Non-Reentrant与Zombie问题 #

你开了-XX:-BackgroundCompilation后情况好转，说明多线程竞争编译是诱因，但根本还是重复编译的触发：

• 如果你的场景不需要分层编译，可以直接关掉：-XX:-TieredCompilation，直接用C2编译，减少中间Tier切换带来的non-reentrant状态。但要注意，关掉分层编译会让首次启动变慢，因为所有编译都要等C2完成。
• 对于确定不会动态修改的核心业务方法，可以用-XX:CompileCommand=compileonly,com/yourpackage/YourClass::yourMethod强制提前编译，避免运行时反复编译。

4. 考虑升级JDK版本 #

AdoptJDK 11.0.7是2020年的老版本了，里面可能存在一些分层编译的bug：

• 建议升级到AdoptJDK 11的最新补丁版本（比如11.0.22及以上），后续版本修复了不少编译系统的稳定性问题，尤其是重复编译和zombie方法的问题。

总结一下 #

你的问题本质是音频处理场景的动态特性（JNI/动态字节码）+ JDK旧版本的编译bug + 分层编译默认参数不匹配共同导致的。先通过详细日志定位重复编译的具体原因，再针对性调整参数或修复代码中的动态操作，最后考虑升级JDK版本，应该能解决大部分问题。

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