Java 为什么park/unpark有60%的CPU使用率？

最近，我们开始使用YJP11.0.9对我们的应用程序（基于XMPP的聊天服务器）进行压力测试。在我们的测试中，我们注意到以下奇怪的行为

采样显示sun.misc.Unsafe.unpark（对象）占用了60%的CPU

对于同一个应用程序，跟踪显示LockSupport.park（对象）占用了52%的CPU

我做了多次测试来确认结果，每次都得到类似的结果

我无法理解为什么unpark需要60%的时间，为什么跟踪显示完全相反的结果

有人能帮我理解这些结果吗。我是不是遗漏了什么

环境：

java -version java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode) java版本 java版本“1.6.0_31” Java（TM）SE运行时环境（build 1.6.0_31-b04）

---

Java HotSpot（TM）64位服务器虚拟机（构建20.6-b01，混合模式）使用某些低级阻塞命令，如读/写/驻车/锁，“CPU”时间被高估，因为它假设在实际操作阻塞时消耗CPU。事实上，unpark/park都很高，这确实表明您有问题，但我怀疑您应该将这两个百分比中的较低者作为估计值。

高CPU时间的

不安全。unpark

是过度上下文切换的标志。以下是一篇文章，旨在了解上下文切换的成本有多高：

要了解Linux上的CS计数，最简单的方法是运行

vmstat

---

一旦确认了高CS（例如，每核/每秒超过10K个交换机），您就可以使用有问题的线程（您可以根据CPU时间在YJP中对线程进行排序）并运行

strace-p-c

以找出切换的原因，例如，线程正在从插槽中读取数据，并将其关闭，在这种情况下，增加套接字缓冲区可能会有所帮助。

如果调用

unpark

几乎是线程所做的唯一一件事，那么可能需要这么多时间。“跟踪显示完全相反的结果”是什么意思？跟踪是否可能度量在方法中花费的时间

park

是一种阻塞方法，所以在其中花费时间也就不足为奇了。@MarkoTopolnik线程还做其他事情。基本上是它的生产者/消费者问题。生成任务并在队列中提交，并通知等待的消费者。使用者对任务进行操作，如果没有可用的任务，则停止自身。调用

unpark

的线程不是正在进行unpark的线程。反过来，该线程除了解析适当的消费线程之外，可能实际上只做了很少的工作。至于

驻车

的CPU时间，a）由于阻塞而难以测量，b）不相关，因为它只占驻车状态下实际花费时间的很小一部分。@MarkoTopolnik在抽样测试中，60%的CPU用于解列。在跟踪测试中，52%的CPU用于从消费者线程执行park。@MarkoTopolnik，正如我所说的，生产者执行CPU活动，如xml解析，这应该比执行unpark要高得多。