[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上,应用的性能都不能依赖于对线程设置优先级。假设某些任务的优先级确实高于另外一些任务,那么这一点须要被应用程序的逻辑来完毕,而不是通过设置线程的优先级来完毕。
一个办法将任务分配给不同的线程池,然后设置这些线程池的规模。
posted on 2017-08-05 10:24 gavanwanggw 阅读(216) 评论(0) 编辑 收藏 举报