多核上的jvm

如果不同线程中的共享资源之间存在明显的争用,那么锁定和解锁对象可能需要大量的资源 IPI

如果应用程序有方法,这可能是一个问题 too-fine-grained locking

Java的“每个对象都是互斥对象”可能会导致运行系统中的锁太多,如果有太多的锁是活动的和争用的。

我毫不怀疑有人会有意编写这样的应用程序,但这可能并不常见。大多数开发人员都会编写应用程序,尽可能减少资源争用。

我怀疑“很多”部分。

我的猜测是,将状态从一个cpu转移到另一个cpu的代价是非常高的。通常,您希望作业保持在同一cpu上,以便尽可能多地在本地缓存其数据。

这完全是猜测,没有文章/数据的问题,但有一些类型的程序不太适合并行-也许应用程序从来没有CPU限制(意味着CPU不是瓶颈,也许某种类型的I/O是)。

这并没有Java特有的原因,但将状态从一个核心移动到另一个核心,甚至从一个CPU移动到另一个CPU都需要时间。如果进程停留在一个内核上,那么这个时间可以得到更好的利用。此外,在这种情况下还可以改进缓存。

只有当程序不使用多个线程并且因此可以有效地将其工作分配到多个核心/cpu时,这才是相关的。

应用程序可能很难利用阻塞线程间通信。然而,这完全是因为应用程序的编程非常糟糕。

没有任何理由可以解释为什么任何编程平平的多核应用程序在多核上运行的速度会慢一些,这些应用程序具有适度的可并行工作负载。

从纯性能的角度来看,挑战通常围绕着内存子系统。因此,虽然更多的cpu通常是好的,但是拥有不靠近Java对象所在内存的cpu是非常非常昂贵的。它非常特定于机器,并且在很大程度上取决于每个CPU和内存之间的确切路径。英特尔和AMD都有不同的外形/速度,结果差别很大。

NUMA 因为多核可能会阻碍。

下面是对内存障碍的一个非常简洁的解释,它还提供了一种查看JIT代码的简洁技术: http://www.infoq.com/articles/memory_barriers_jvm_concurrency

这并不是说所有的应用程序都能从一个内核上获益。

最近的Intel CPU具有Turbo Boost:

http://en.wikipedia.org/wiki/Intel_Turbo_Boost

这将取决于应用程序生成的线程数。如果你生成了四个工作线程来处理大量的数字运算,那么这个应用程序在四核机器上的速度会快四倍,这取决于你必须做多少簿记和合并工作。