Apple M1平台Zulu OpenJDK 8调试Step Over执行极慢问题

• Zulu OpenJDK 8 早期ARM64（M1系列芯片适配）版本的 JDWP（Java调试线协议） 实现存在性能缺陷：单步执行（step over/step into）时，JDWP需要持续监听方法出入口事件、校验当前执行位置是否到达单步终点，该版本在ARM64架构下的事件回调、上下文切换逻辑未做优化，额外开销极高。
• BouncyCastleProvider初始化逻辑本身极重：实例化+注册安全提供者的过程会加载上百个加密算法类、注册数百个安全服务条目，产生数万次内部方法调用。单步跳过整个test()方法时，JDWP会拦截所有这些内部方法的执行事件，进一步放大了性能缺陷带来的耗时影响。
• 不同执行模式、JDK版本的耗时差异可以佐证上述逻辑：
  • 执行resume（恢复运行）时，JDWP不会开启单步事件监听，仅在命中预设断点时才会暂停，没有额外拦截开销，因此Zulu JDK8下耗时仅93ms，和JDK17的85ms基本持平。
  • Oracle JDK17的JDWP实现已经针对ARM64架构做了完整的指令级优化，单步事件处理效率比JDK8高一个数量级以上，因此即使开启step over，耗时也仅837ms，属于正常范围。

• 升级Zulu OpenJDK 8到最新小版本：Azul在2022年及之后推送的Zulu JDK8更新已经修复了M1芯片下JDWP单步执行的性能问题，升级后单步执行重逻辑方法的耗时会下降到和JDK17接近的水平。
• 调整BouncyCastle加载时机：将Security.addProvider(new BouncyCastleProvider())逻辑放到应用启动最早期、所有调试断点之前的位置（比如类静态初始化块），避免在单步执行路径上触发BouncyCastle的重初始化逻辑。
• 配置IDE单步过滤规则：以IntelliJ IDEA为例，进入Build, Execution, Deployment > Debugger > Stepping设置页，将org.bouncycastle.*、java.security.*包加入单步过滤列表。开启过滤后step over时JDWP不会拦截这些包内部的方法调用事件，单步耗时会直接降到和resume相当的水平。
• 临时规避操作：如果暂时无法升级JDK或修改配置，遇到需要跳过耗时方法的场景时，直接在目标方法的下一行打断点，使用resume运行到下一个断点即可，完全不会产生单步执行的额外开销。

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