我们最近在生产环境中看到了 CPU 消耗高的问题，并且在调试时发现了一些奇怪的问题。当我执行“top -H”来查看每个线程 ID 的 CPU 统计信息时，我发现一个线程 X 消耗了高 CPU。当我进行线程转储时，我看到这个线程 X 处于 BLOCKED 状态。这是什么意思，处于 BLOCKED 状态的线程可以消耗高 CPU 吗？我认为这可能是一个微不足道的问题，但我是调试性能问题和 JVM 的新手，不确定我可能在这里遗漏了什么。
【问题讨论】：
BLOCKED 状态。根据实现的不同，线程也有可能会消耗 CPU 周期以不成功地尝试离开 BLOCKED 状态。
标签： jvm cpu-usage thread-dump apm
进入和退出 BLOCKED 状态可能会很昂贵。如果你被阻塞了一小会儿，这不是问题，但如果你在繁忙的循环中短暂阻塞，你的线程可能看起来被阻塞，但实际上是在烧 CPU。
我会寻找多个线程反复竞争共享资源，这些资源非常短暂地进入 BLOCKED。
【讨论】：
@Peter 已经提到过繁忙循环（它可能是 JVM 内部 adaptive optimization 的自旋锁，以防同步或应用程序本身在某些情况下创建繁忙循环），这可能会消耗 CPU。还有另一种间接方式，由于线程阻塞，CPU 可能会变得非常高。通常在 Web 服务器中，如果许多线程处于阻塞状态（不是因为与同步锁相关的阻塞，而是说等待来自后端数据存储的 IO），那么它可能会给 JVM 垃圾收集带来很大压力。这些工作线程应该快速完成它们的工作，以便它们在堆上创建的所有对象都被快速取消引用并收集垃圾。如果很多线程都处于这种状态，那么垃圾收集线程必须超时工作，最终可能会占用大量 CPU。
【讨论】：