1.JVM线程优化

1.1.当空间不足时,可以调整线程使用的内存

1.2.每个线程都有一个原生栈,操作系统会在这里存储线程的调用栈信息

1.3.原生栈的大小是1 MB

  • 1.3.1.32位的Windows JVM原生栈大小是320KB

  • 1.3.2.在64位的JVM中,通常不会修改这个值

    • 1.3.2.1.除非机器的物理内存相当紧张
  • 1.3.3.较小的栈大小可以防止应用程序用完原生内存

    • 1.3.3.1.许多程序可以在栈大小为256 KB时运行

    • 1.3.3.2.很少有程序需要用到完整的1 MB

1.4.-Xss=N标志

  • 1.4.1.改变线程的栈大小

2.原生内存溢出

2.1.在32位的JVM中,进程使用的内存达到了4 GB(或者小于4 GB,取决于操作系统)的最大大小

2.2.系统实际已经耗尽虚拟内存

2.3.减小栈的大小可以解决

2.4.在Unix风格的系统上,用户创建的进程(他们正在运行的所有程序)已经达到了此次登录配置的最大进程数

  • 2.4.1.单个线程被认为是一个进程

2.5.无法从JVM的异常中判断是这三种情况中的哪一种

3.偏向锁

3.1.让锁偏向于最近访问锁的线程

  • 3.1.1.如果一个线程最近使用了某个锁,那么下次它执行被同一个锁保护的代码时,处理器的缓存更有可能还包含该线程需要的数据

3.2.但是偏向锁需要簿记信息,所以有时机器性能会更糟糕

3.3.使用线程池的应用程序(包括某些应用程序和REST服务器)在偏向锁生效时,往往表现得更差

3.4.-XX:-UseBiasedLocking

  • 3.4.1.禁用偏向锁

  • 3.4.2.默认开启的

4.线程优先级

4.1.每个Java线程都有一个由开发人员定义的优先级,这是对操作系统的一种提示,用来说明程序认为特定线程有多重要

4.2.操作系统会为机器上运行的每个线程计算一个当前优先级

  • 4.2.1.当前优先级既考虑了Java分配的优先级,也考虑了许多其他因素

  • 4.2.2.最重要的因素是线程上次运行到现在有多长时间

  • 4.2.3.无论其优先级如何,都不会有线程因为等待访问CPU而“饥饿”

4.3.在Windows上,Java优先级较高的线程往往比优先级较低的线程运行得更多,但即使是低优先级的线程也会获得相当多的CPU时间

4.4.无论在哪种情况下,都不能依赖线程的优先级来决定它的运行频率

4.5.如果某些任务比其他任务更重要,就必须使用应用程序逻辑来确定它们的优先级

5.监控线程和锁

5.1.线程的总数

  • 5.1.1.通过系统提供的基本线程信息可以大致了解运行的线程数量

  • 5.1.2.确保它不会太高或太低

5.2.查看线程信息可以确定线程被阻塞的原因

  • 5.2.1.它们在等待资源

  • 5.2.2.它们在等待I/O

5.3.查看线程

  • 5.3.1.jconsole

    • 5.3.1.1.显示JVM内的线程状态

5.4.查看阻塞线程

  • 5.4.1.Java飞行记录器JFR

    • 5.4.1.1.可以查看JVM内部、并能在底层知道线程何时被阻塞

    • 5.4.1.2.提供了一个简单的方法来检查导致线程阻塞的事件

  • 5.4.2.jstack

    • 5.4.2.1.提供虚拟机中每个线程的状态信息,包括线程是否在运行、是否在等待锁、是否在等待I/O

    • 5.4.2.2.在一定程度上可以查看线程阻塞在什么资源上

  • 5.4.3.大量的阻塞线程会降低性能。不管是什么原因造成的阻塞,都需要改变配置或应用程序,以避免阻塞

6.线程性能没有太多可以优化

6.1.可以调整的JVM标志相对较少

6.2.这些标志的效果也十分有限

6.3.良好的线程性能最佳实践准则

  • 6.3.1.管理线程数

  • 6.3.2.限制同步影响