java线程切换消耗时间,如何衡量在Java平台下的上下文切换中花费的时间

由于线程切换和内存缓存争用引起的浪费，您无法轻易区分浪费。您可以测量线程争用。即，在l​​inux上，您可以cat / proc / PID / XXX，并获得大量详细的每线程统计信息。然而，由于先发制人的调度程序不会在脚下拍摄，所以不管你使用多少线程，每秒都不会说30 ctx的开关。而那段时间将是相对的小vs你正在做的工作量。上下文切换的实际成本是缓存污染。例如一旦您重新进行上下文切换，您很可能会主要缓存未命中。因此，操作系统时间和上下文切换计数的最小值。

线程间高速缓存行肮脏的比例是多少有价值的。根据CPU的不同，高速缓存行脏后跟对等CPU读取是SLOWER而不是缓存缺失 – 因为您必须强制对等CPU将其值写入main-mem，才能开始阅读。一些CPU可以让您从对等缓存行拉扯，而不会碰到主机。

所以关键是绝对最小化任何共享修改的内存结构..使所有内容尽可能只读。这包括共享FIFO缓冲区(包括执行程序池)..即使您使用同步队列 – 然后每个sync-op是共享的脏内存区域。而且，如果速度足够高，它可能会触发操作系统陷阱停顿，等待对等线程的互斥体。

理想的是分段RAM，分配给固定数量的工作人员一个大的工作单位，然后使用倒计时锁存器或其他一些内存障碍(使每个​​线程只能触摸一次)。理想情况下，预先分配任何临时缓冲区，而不是进出共享内存池(然后导致缓存争用)。 Java’synchronized’块利用(幕后)一个共享的哈希表存储空间，从而触发不期望的脏读，我还没有确定java 5 Lock对象是否避免了这个问题，但是你仍然利用OS帮助您的吞吐量。显然，大多数OutputStream操作触发这样的同步调用(当然通常填充一个公共流缓冲区)。

一般来说，我的经验是，单线程比通用字节数组/对象数组等的多线程速度更快。至少使用我已经尝试过的简单排序/过滤算法。在我的经验中，Java和C都是这样。我没有尝试FPU内部操作(如分割，sqrt)，其中缓存线可能不太重要。

基本上，如果你是一个单一的CPU，你没有缓存线问题(除非操作系统总是刷新缓存，即使在共享线程)，但是多线程购买你不是什么。在超线程中，这是一回事。在单CPU共享的L2 / L3缓存配置(例如AMD)中，您可能会发现一些好处。在多CP​​U Intel BUS中，忘了它 – 共享写入内存比单线程差。