问题
我有一段 java 代码(JDK 1.6.0._22，如果相关)实现了一个无状态、无副作用且没有互斥锁的函数。但是它确实使用了大量内存(我不知道这是否相关)。
过去我访问过 Sun 实验室并收集了标准的“性能与线程数”曲线。由于此函数没有互斥锁，因此它有一个漂亮的图形，尽管垃圾收集随着线程数量的增加而启动。经过一些垃圾收集调整后，我能够使这条曲线几乎平坦。
我现在正在英特尔硬件上做同样的实验。硬件有 4 个 CPU，每个 8 个内核和超线程。这给出了 64 个 availableProcessors()。不幸的是，“性能与线程数”的曲线对于 1、2、3 个线程和 3 个线程的上限很好地缩放。在 3 个线程之后，我可以在任务中放置任意多的线程，性能也没有变好
尝试解决问题
我的第一个念头是我愚蠢地在某处引入了一些同步代码。通常为了解决这个问题，我运行 JConsole 或 JVisualVM，并查看线程堆栈跟踪。如果我有 64 个线程以 3 的速度运行，我希望其中有 61 个线程等待进入互斥锁。我没有找到这个。相反，我发现所有线程都在运行:非常慢。
第二个想法是计时框架可能引入了问题。我用一个虚拟函数替换了我的函数，该函数使用 AtomicLong 计数为十亿。这与线程数量成比例:与 1 个线程相比，使用 64 个线程我可以数到 10,000 次 64 倍。
我想(绝望)也许垃圾收集需要很长时间，所以我调整了垃圾收集参数。虽然这改善了我的延迟变化，但它对吞吐量没有影响:我仍然有 64 个线程以我期望的 3 个运行速度运行。
我已经下载了intel工具VTunes，但是我的技能很薄弱:它是一个复杂的工具，我还不了解它。我有订购的说明书:送给自己的一份有趣的圣诞礼物，但这对解决我当前的问题有点太晚了
问题
- 我可以使用哪些工具(心理或软件)来提高我对正在发生的事情的理解？
- 除了互斥锁或垃圾回收之外还有哪些机制会降低我的代码速度？
最佳答案
I have a piece of java code (JDK 1.6.0._22 if relevant)
从那时起，性能有了相当大的改进。我会尝试 Java 6 update 37 或 Java 7 update 10。
It does however use a lot of memory
这可能意味着您访问数据的方式可能很重要。访问主内存中的数据可能比在主缓存中慢 20+x。这意味着您必须保守地访问数据并充分利用您访问的每条新数据。
After 3 threads I can put as many threads as I want to the task, and the performance gets no better Instead I found all the threads running: just very slowly.
这表明您正在最大限度地使用资源。考虑到您正在使用的内存量，最有可能被最大化的资源是 cpu 到主内存桥。我怀疑你有一个 64 线程的桥!这意味着您应该考虑可能使用更多 cpu 但改进访问内存的方式(更少随机和更多顺序)并在您这样做时减少卷(尽可能使用更紧凑的类型)。例如我有“带两位小数的短”类型而不是 float ，它可以使用一半的内存。
正如您观察到的，当每个线程都更新它自己的私有(private) AtomicLong 时，您将获得线性可伸缩性。这根本不会使用 cpu 到主内存的桥接。
来自@Marko
Peter, do you have an idea how these multicore architectures work with memory, anyway?
没有我想要的那么多，因为这个问题对 Java 不可见。
Does each core have an independent channel?
每个核心都有一个独立的主缓存 channel 。对于外部缓存，每个或 2-6 个缓存区域可能有一个 channel ，但在重负载下会发生大量冲突。
对于通往主内存的桥梁，有一个非常宽的 channel 。这有利于长顺序访问，但对随机访问非常不利。单个线程可以通过随机读取将其最大化(足够随机，它们不适合外部缓存)
Or at least independent as long at there are no collisions?
一旦您耗尽了主缓存(L1 通常为 32 KB)，它就会一直发生冲突。
Because otherwise scaling is a great issue.
正如 OP 所展示的那样。大多数应用程序要么 a) 花费大量时间等待 IO b) 分配对小批量数据的计算。对大量数据进行计算分配是最糟糕的情况。
我处理这个问题的方法是在内存中安排我的数据结构以便顺序访问。我使用堆外内存，这很痛苦，但可以让您完全控制布局。 (我的源数据是为持久性而映射的内存)我通过顺序访问将数据流式传输并尝试充分利用这些数据(即我尽量减少重复访问)即使有 16 个内核，也很难假设所有这些内核都会被使用效率很高，因为我在任何时候都有 40 GB 的源数据和大约 80 GB 的派生数据。
注意:高端 GPU 通过具有令人难以置信的高内存带宽解决了这个问题。高端处理器可以获得 250 GB/秒，而典型的 CPU 约为 4-6 GB/秒。即便如此，它们更适合矢量化处理，并且它们引用的峰值性能可能几乎没有内存访问，例如曼德尔布洛特集。
关于java - 除了互斥锁或垃圾收集之外还有哪些机制可以减慢我的多线程 Java 程序的速度？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13969076/