[Java Performance] JVM 线程调优

调整线程栈空间

当很缺少内存时，能够调整线程使用的内存。

每一个线程都有一个栈，用来记录该线程的调用栈信息。线程中的栈的默认空间是有OS和JVM的版本号决定的：

OS	32-bit	64-bit
Linux	320 KB	1 MB
Mac OS	N/A	1 MB
Solaris Sparc	512 KB	1 MB
Solaris X86	320 KB	1 MB
Windows	320 KB	1 MB

当栈空间被设置的过小时，可能会由于有较长的调用栈而抛出StackOverflowError。

在64位的JVM中，一般不须要改动这个值。除非内存确实很吃紧。而在32位的JVM中。能够将这个值从320KB设置成128KB，为了给堆内存腾出很多其它的空间。

更改线程栈空间的指令：-Xss=N 比方：-Xss=256k

偏见锁(Biased
Locking)

当锁被多个线程所争夺时。JVM和OS能够选择将锁分配给哪个线程。能够使用一种公平的策略将锁分配给其它线程，或者也能够使用一种不公平(偏见)的策略。比方将锁再分配给上一次拥有该锁的线程。

将锁再次分配给上一次拥有该锁的线程，这样做的合理性在于：因为时间上的连续性，处理器中可能还缓存着和该线程所运行任务相关的数据。因此当线程再次运行时。准备上下文的时间就行节省下来。

当然，使用偏见锁本身须要记录一些相关数据，因此在某些时候反而会对性能有影响。

典型的比方，在非常多时候，假设将偏见锁应用在线程池中。那么性能反而会变差。假设一个应用并不须要使用偏见锁来作为锁分配的策略，那么能够通过：-XX:-UseBiasedLocking 来禁用它，由于默认是会启用偏见锁的，禁用它会提升些许性能。

锁的自旋(Lock
Spinning)

对于没有得到锁的线程。JVM有两种处理方式：

让线程进入一个忙循环(Busy Loop)。待它运行了一些指令后会再次检查须要的锁是否可用。
让线程进入一个队列，当须要的锁可用时通知它。此时CPU能够被其他线程使用。

假设处于竞争中的锁仅仅须要被持有一小段时间，那么使用第一种忙循环(也被称为线程自旋(Thread Spinning))的速度会比另外一种让线程进入队列的方式快的多。反之，当竞争中的锁会被线程持有较长的时间时，使用另外一种方式更优。这可以让CPU的有效利用率更高。

JVM会合理地选择使用哪种处理方式。首先会让线程自旋一段时间，假设还没有得到须要的锁，就会将该线程放入队列中等待，从而让出CPU资源给其他线程。

线程优先级

在Java API中。每一个线程都可以被设置一个优先级，OS会參考这个值。可是注意OS不过“參考”，并不一定会遵循它。OS会对每一个执行中的线程计算一个“当前”优先级。这个计算过程会考虑到设置的优先级，可是它不过众多因素中的一个。当中最重要的因素往往是这个线程已经执行了多长时间。

考虑这个因素是为了让每一个线程都可以得到执行的机会。

所以，不管线程被设置的优先级有多低，它们也总可以得到执行的机会。

另外，设置的线程优先级在不同的OS上的权重是不同的。

在基于Unix的系统上，线程的运行时间是主导线程当前优先级的因素，也就是说设置的线程优先级差点儿不会被“參考”。而在Windows系统上。设置的线程优先级的权重会略微高一些。

所以。不管是在哪个OS上，应用的性能都不能依赖于对线程设置优先级。假设某些任务的优先级确实高于另外一些任务，那么这一点须要被应用程序的逻辑来完毕，而不是通过设置线程的优先级来完毕。

一个办法将任务分配给不同的线程池，然后设置这些线程池的规模。