JDK6运行时性能优化

Synchronized性能优化：

• 粗化锁区域：通过扩大已存在锁，减少unlock和re-lock操作，降低所开销；默认启用，启用参数：-XX:+EliminateLocks
• 同步削减：通过逃逸分析，削减线程局部变量上的锁；启用参数：-XX:+DoEscapeAnalysis
• 偏袒锁机制：延长创建锁机制线程上锁的租约，知道有其他线程竞争锁时才释放(个人理解：相当于延长锁时间，减少释放、获取锁开销)；默认启用，启用单数：-XX:+UseBiasedLocking
• 通过Adaptive Spinning提升同步性能：这个没有看明白；原文放在最下边，望大牛指导；

其他性能优化：

• 数组拷贝性能优化
• AMD和Intel64位平台支持大页堆；默认，Solaris默认启用
• 其他HotSpot编译器提升：1.client 编译器后台编译 2.更好的性能实现

Adaptive Spinning原文：

The  Synchronized  implementation also provides adaptive spinning, whereas ReentantLock currently does not. Adaptive spinning employs a two-phase spin-then-block strategy. Briefly, on multiprocessor systems a contended synchronized enter attempt will spin briefly before blocking in order to avoid context switching. Context switching is wasted work -- it doesn't contribute toward forward progress of the application. Worse, it causes TLBs and caches to be repopulated when the blocked thread eventually resumes. (This is the so-called "cache reload transient"). The spin duration varies as a function of the success/failure ratio of recent spin attempts on that same monitor, so the mechanism adapts automatically to parallelism, current system load, application modality, critical section length, etc. In addition, we avoid spinning for a lock where the current lock owner is itself blocked and unlikely to release the lock in a timely fashion. On solaris our checks can be more refined, determining if the target thread is ONPROC (running), for instance, via the  contract private   thr_schedctl  interface. And it should go without saying that we spin "politely", using a backoff to avoid generating excessive and wasteful traffic on the coherency bus, as well as using PAUSE on IA32 and AMD64 platforms. We'll likely add spinning support to ReentrantLock in a future release.