收费的网站怎么做,成立公司需要几个人,网站备案账号密码,产品设计培训中心单线程程序既不存在线程调度#xff0c;也不存在同步开销#xff0c;而且不需要使用锁来保证数据结构的一致性。在多个线程的调度和协调过程中都需要一定的性能开销#xff1a;对于为了提升性能而引入的线程来说#xff0c;并行带来的性能提升必须超过并发导致的开销。 上下…单线程程序既不存在线程调度也不存在同步开销而且不需要使用锁来保证数据结构的一致性。在多个线程的调度和协调过程中都需要一定的性能开销对于为了提升性能而引入的线程来说并行带来的性能提升必须超过并发导致的开销。 上下文切换
如果主线程是唯一的线程那么它基本上不会被调度出去。另一方面如果可运行的线程数大于CPU的数量那么操作系统最终会将某个正在运行的线程调度出来从而使其他线程能够使用CPU。这将导致一次上下文切换在这个过程中将保存当前运行线程的执行上下文并将新调度进来的线程的执行上下文设置为当前上下文。
切换上下文需要一定的开销而在线程调度过程中需要访问由操作系统和JVM共享的数据结构。应用程序、操作系统以及JVM都使用一组相同的CPU。在JVM 和操作系统的代码中消耗越多的CPU时钟周期应用程序的可用CPU时钟周期就越少。但上下文切换的开销并不只是包含JVM和操作系统的开销。当一个新的线程被切换进来时它所需要的数据可能不在当前处理器的本地缓存中因此上下文切换将导致一些缓存缺失因而线程在首次调度运行时会更加缓慢。这就是为什么调度器会为每个可运行的线程分配一个最小执行时间即使有许多其他的线程正在等待执行它将上下文切换的开销分摊到更多不会中断的执行时间上从而提高整体的吞吐量(以损失响应性为代价)。
当线程由于等待某个发生竞争的锁而被阻塞时JVM通常会将这个线程挂起并允许它被交换出去。如果线程频繁地发生阻塞那么它们将无法使用完整的调度时间片。在程序中发生越多的阻塞(包括阻塞I/O等待获取发生竞争的锁或者在条件变量上等待)与CPU密集型的程序就会发生越多的上下文切换从而增加调度开销并因此而降低吞吐量。
上下文切换的实际开销会随着平台的不同而变化然而按照经验来看在大多数通用的处理器中上下文切换的开销相当于5000~10000个时钟周期也就是几微秒。
UNIX 系统的vmstat 命令和Windows系统的perfmon 工具都能报告上下文切换次数以及在内核中执行时间所占比例等信息。如果内核占用率较高(超过10%)那么通常表示调度活动发生得很频繁这很可能是由I/O或竞争锁导致的阻塞引起的。 内存同步
同步操作的性能开销包括多个方面。在synchronized 和volatile 提供的可见性保证中可能会使用一些特殊指令即内存栅栏(Memory Barrier)。内存栅栏可以刷新缓存使缓存无效刷新硬件的写缓冲以及停止执行管道。内存栅栏可能同样会对性能带来间接的影响因为它们将抑制一些编译器优化操作。在内存栅栏中大多数操作都是不能被重排序的。
在评估同步操作带来的性能影响时区分有竞争的同步和无竞争的同步非常重要。synchronized 机制针对无竞争的同步进行了优化(volatile 通常是非竞争的)而在编写本书时一个“快速通道(Fast-Path)”的非竞争同步将消耗20~250个时钟周期。虽然无竞争同步的开销不为零但它对应用程序整体性能的影响微乎其微而另一种方法不仅会破坏安全性而且还会使你(或者后续开发人员)经历非常痛苦的除错过程。
现代的JVM能通过优化来去掉一些不会发生竞争的锁从而减少不必要的同步开销。如果一个锁对象只能由当前线程访问那么JVM就可以通过优化来去掉这个锁获取操作因为
另一个线程无法与当前线程在这个锁上发生同步。例如JVM通常都会去掉程序清单11-2中的锁获取操作。
一些更完备的JVM 能通过逸出分析(Escape Analysis)来找出不会发布到堆的本地对象引用(因此这个引用是线程本地的)。在程序清单11-3 的getStoogeNames中,对List的唯一引用就是局部变量stooges并且所有封闭在栈中的变量都会自动成为线程本地变量。在getStoogeNames的执行过程中,至少会将Vector上的锁获取/释放4次,每次调用add或toString时都会执行1次。然而一个智能的运行时编译器通常会分析这些调用从而使stooges 及其内部状态不会逸出因此可以去掉这4次对锁获取操作。 程序清单11-3 可通过锁消除优化去掉的锁获取操作
public String getStoogeNames(){
ListStringstooges new VectorString();
stooges. add(Moe);
stooges. add(Larry);
stooges. add(Curly);
return stooges. toString();
} 即使不进行逸出分析编译器也可以执行锁粒度粗化(Lock Coarsening)操作即将邻近的同步代码块用同一个锁合并起来。在getStoogeNmnes中如果JVM 进行锁粒度粗化那么可能会把3个add 与1个toString调用合并为单个锁获取/释放操作并采用启发式方法来评估同步代码块中采用同步操作以及指令之间的相对开销。②这不仅减少了同步的开销同时还能使优化器处理更大的代码块从而可能实现进一步的优化。
不要过度担心非竞争同步带来的开销。这个基本的机制已经非常快了并且JVM还能进行额外的优化以进一步降低或消除开销。因此我们应该将优化重点放在那些发生锁竞争的地方。
某个线程中的同步可能会影响其他线程的性能。同步会增加共享内存总线上的通信量总线的带宽是有限的并且所有的处理器都将共享这条总线。如果有多个线程竞争同步带宽那么所有使用了同步的线程都会受到影响。 这个编译器优化也被称为锁消除优化(Lock Elision),IBM 的JVM 支持这种优化,并且预期从Java 7 开始在HotSpot中支持。
一个智能的动态编译器会发现该方法总是返回相同的字符串因此在第一次执行后把getStoogeNames重新编译为仅返回第一次执行的结果。 阻塞
非竞争的同步可以完全在JVM中进行处理(Bacon等1998)而竞争的同步可能需要操作系统的介入从而增加开销。当在锁上发生竞争时竞争失败的线程肯定会阻塞。JVM在实现阻塞行为时可以采用自旋等待(Spin-Waiting指通过循环不断地尝试获取锁直到成功)或者通过操作系统挂起被阻塞的线程。这两种方式的效率高低要取决于上下文切换的开销以及在成功获取锁之前需要等待的时间。如果等待时间较短则适合采用自旋等待方式而如果等待时间较长则适合采用线程挂起方式。有些JVM将根据对历史等待时间的分析数据在这两者之间进行选择但是大多数JVM在等待锁时都只是将线程挂起。
当线程无法获取某个锁或者由于在某个条件等待或在I/O操作上阻塞时需要被挂起在这个过程中将包含两次额外的上下文切换以及所有必要的操作系统操作和缓存操作被阻塞的线程在其执行时间片还未用完之前就被交换出去而在随后当要获取的锁或者其他资源可用时又再次被切换回来。(由于锁竞争而导致阻塞时线程在持有锁时将存在一定的开销当它释放锁时必须告诉操作系统恢复运行阻塞的线程。)
