Vert.x Http1xServerConnection致JMC Java Monitor Blocked，是否存性能问题？

核心结论 #

这种情况不一定意味着存在严重性能问题，需要结合阻塞时长、频率以及服务实际运行指标综合判断，Vert.x内部使用synchronized是符合其设计逻辑的。

为什么会出现大量Blocked事件？ #

• Vert.x的同步设计逻辑：虽然Vert.x基于单线程事件循环模型，但Http1xServerConnection的状态可能在一些跨线程场景下被修改（比如超时回调、外部事件触发的连接状态变更），这时候synchronized是必要的同步手段。官方文档提到的“同一事件循环使用时偏向锁降开销”是理想场景，但实际运行中一旦出现跨线程访问，偏向锁会升级为轻量/重量锁，进而出现锁竞争和Blocked事件。
• JDK17偏向锁的限制：JDK17中偏向锁已被标记为弃用，即便手动开启，若代码路径中出现过锁竞争（比如多个线程尝试获取同一锁），偏向锁会被撤销并升级，无法再回到偏向状态，所以开启偏向锁也不会改善当前的Blocked情况。

如何判断是否需要担忧性能？ #

• 看阻塞时长：如果单次阻塞是微秒/毫秒级，对事件循环的影响极小，Vert.x的事件循环可以容忍这类短暂阻塞；如果出现秒级的长时间阻塞，才会显著影响服务性能，需要重点排查。
• 看阻塞频率：统计单位时间内Blocked事件的次数，如果阻塞占比超过CPU总运行时间的10%，或者每个请求都触发多次阻塞，需要关注；如果只是偶发，无需紧张。
• 结合服务实际指标：如果服务的QPS、响应时间、错误率等核心指标都正常，即便JMC显示有Blocked事件，也不用过度担心；反之如果指标出现异常，再深入分析。

排查优化方向 #

• 检查业务代码是否跨线程操作连接对象：避免在非事件循环线程中调用HttpConnection的close、write等方法，这类操作会触发跨线程锁竞争。
• 升级Vert.x版本：部分旧版本的Http1xServerConnection存在锁竞争的已知问题，升级到最新稳定版可能解决此类问题。
• 用JFR深入分析锁竞争：在JMC的Lock Contention视图中，定位具体触发锁竞争的代码路径，区分是Vert.x内部逻辑还是业务代码导致的问题。

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