通过 Java 线程堆栈进行性能瓶颈分析

改善性能意味着用更少的资源做更多的事情。为了利用并发来提高系统性能，我们需要更有效的利用现有的处理器资源，这意味着我们期望使 CPU 尽可能出于忙碌状态（当然，并不是让 CPU 周期出于应付无用计算，而是让 CPU 做有用的事情而忙）。如果程序受限于当前的 CPU 计算能力，那么我们通过增加更多的处理器或者通过集群就能提高总的性能。总的来说，性能提高，需要且仅需要解决当前的受限资源，当前受限资源可能是：

  • CPU： 如果当前 CPU 已经能够接近 100% 的利用率，并且代码业务逻辑无法再简化，那么说明该系统的性能以及达到上线，只有通过增加处理器来提高性能
  • 其他资源：比如连接数等。可以修改代码，尽量利用 CPU，可以获得极大的性能提升

如果你的系统有如下的特点，说明系统存在性能瓶颈：

  • 随着系统逐步增加压力，CPU 使用率无法趋近 100%（如下图）

  • 持续运行缓慢。时常发现应用程序运行缓慢。通过改变环境因子（负载，连接数等）也无法有效提升整体响应时间

  • 系统性能随时间的增加逐渐下降。在负载稳定的情况下，系统运行时间越长速度越慢。可能是由于超出某个阈值范围，系统运行频繁出错从而导致系统死锁或崩溃
  • 系统性能随负载的增加而逐渐下降。

一个好的程序，应该是能够充分利用 CPU 的。如果一个程序在单 CPU 的机器上无论多大压力都不能使 CPU 使用率接近 100%，说明这个程序设计有问题。一个系统的性能瓶颈分析过程大致如下：

  1. 先进性单流程的性能瓶颈分析，受限让单流程的性能达到最优。
  2. 进行整体性能瓶颈分析。因为单流程性能最优，不一定整个系统性能最优。在多线程场合下，锁争用?给也会导致性能下降。

高性能在不同的应用场合下，有不同的含义：

  1. 有的场合高性能意味着用户速度的体验，如界面操作等
  2. 有的场合，高吞吐量意味着高性能，如短信或者彩信，系统更看重吞吐量，而对每一个消息的处理时间不敏感
  3. 有的场合，是二者的结合

性能调优的终极目标是：系统的 CPU 利用率接近 100%，如果 CPU 没有被充分利用，那么有如下几个可能：

  1. 施加的压力不足
  2. 系统存在瓶颈

1 常见的性能瓶颈

1.1 由于不恰当的同步导致的资源争用

1.1.1 不相关的两个函数，公用了一个锁，或者不同的共享变量共用了同一个锁，无谓地制造出了资源争用

下面是一种常见的错误

两个不相干的方法（没有使用同一个共享变量），共用了 this 锁，导致人为的资源竞争上面的代码将 synchronized 加在类的每一个方法上面，违背了保护什么锁什么的原则。对于无共享资源的方法，使用了同一个锁，人为造成了不必要的等待。Java 缺省提供了 this 锁，这样很多人喜欢直接在方法上使用 synchronized 加锁，很多情况下这样做是不恰当的，如果不考虑清楚就这样做，很容易造成锁粒度过大：

  • 即使一个方法中的代码也不是处处需要锁保护的。如果整个方法使用了 synchronized，那么很可能就把 synchronized 的作用域给人为扩大了。在方法级别上加锁，是一种粗犷的锁使用习惯。

上面的代码应该变成下面


这样会导致当前线程占用锁的时间过长，其他需要锁的线程只能等待，最终导致性能受到极大影响1.1.2 锁的粒度过大，对共享资源访问完成后，没有将后续的代码放在synchronized 同步代码块之外

单 CPU 场合 将耗时操作拿到同步块之外，有的情况下可以提升性能，有的场合则不能：上面的代码，会导致一个线程长时间占有锁，而在这么长的时间里其他线程只能等待，这种写法在不同的场合下有不同的提升余地：

    • 同步块的耗时代码是 CPU 密集型代码（纯 CPU 运算等），不存在磁盘 IO/网络 IO 等低 CPU 消耗的代码，这种情况下，由于 CPU 执行这段代码是 100% 的使用率，因此缩小同步块也不会带来任何性能上的提升。但是，同时缩小同步块也不会带来性能上的下降
    • 同步块中的耗时代码属于磁盘/网络 IO等低 CPU 消耗的代码，当当前线程正在执行不消耗 CPU 的代码时，这时候 CPU 是空闲的，如果此时让 CPU 忙起来，可以带来整体性能上的提升，所以在这种场景下，将耗时操作的代码放在同步之外，肯定是可以提高整个性能的（？）
  • 多 CPU 场合 将耗时的操作拿到同步块之外，总是可以提升性能
    • 同步块的耗时代码是 CPU 密集型代码（纯 CPU 运算等），不存在磁盘 IO/网络 IO 等低 CPU 消耗的代码，这种情况下，由于是多 CPU，其他 CPU也许是空闲的，因此缩小同步块可以让其他线程马上得到执行这段代码，可以带来性能的提升
    • 同步块中的耗时代码属于磁盘/网络 IO等低 CPU 消耗的代码，当当前线程正在执行不消耗 CPU 的代码时，这时候总有 CPU 是空闲的，如果此时让 CPU 忙起来，可以带来整体性能上的提升，所以在这种场景下，将耗时操作的代码放在同步块之外，肯定是可以提高整个性能的

不管如何，缩小同步范围，对系统没有任何不好的影响，大多数情况下，会带来性能的提升，所以一定要缩小同步范围，因此上面的代码应该改为


Sleep 的滥用，尤其是轮询中使用 sleep，会让用户明显感觉到延迟，可以修改为 notify 和 wait1.1.3 其他问题

  • String + 的滥用，每次 + 都会产生一个临时对象，并有数据的拷贝
  • 不恰当的线程模型
  • 效率地下的 SQL 语句或者不恰当的数据库设计
  • 不恰当的 GC 参数设置导致的性能低下
  • 线程数量不足
  • 内存泄漏导致的频繁 GC

2.2 性能瓶颈分析的手段和工具

上面提到的这些原因形成的性能瓶颈，都可以通过线程堆栈分析，找到根本原因。

2.2.1 如何去模拟，发现性能瓶颈

性能瓶颈的几个特征：

  • 当前的性能瓶颈只有一处，只有当解决了这一处，才知道下一处。没有解决当前性能瓶颈，下一处性能瓶颈是不会出现的。如下图所示，第二段是瓶颈，解决第二段的瓶颈后，第一段就变成了瓶颈，如此反复找到所有的性能瓶颈

  • 性能瓶颈是动态的，低负载下不是瓶颈的地方，高负载下可能成为瓶颈。由于 JProfile 等性能剖析工具依附在 JVM 上带来的开销，使系统根本就无法达到该瓶颈出现时需要的性能，因此在这种场景下线程堆栈分析才是一个真正有效的方法

鉴于性能瓶颈的以上特点，进行性能模拟的时候，一定要使用比系统当前稍高的压力下进行模拟，否则性能瓶颈不会出现。具体步骤如下：

2.2.2 如何通过线程堆栈识别性能瓶颈

通过线程堆栈，可以很容易的识别多线程场合下高负载的时候才会出现的性能瓶颈。一旦一个系统出现性能瓶颈，最重要的就是识别性能瓶颈，然后根据识别的性能瓶颈进行修改。一般多线程系统，先按照线程的功能进行归类（组），把执行相同功能代码的线程作为一组进行分析。当使用堆栈进行分析的时候，以这一组线程进行统计学分析。如果一个线程池为不同的功能代码服务，那么将整个线程池的线程作为一组进行分析即可。

一般一个系统一旦出现性能瓶颈，从堆栈上分析，有如下三种最为典型的堆栈特征：

  1. 绝大多数线程的堆栈都表现为在同一个调用上下文，且只剩下非常少的空闲线程。可能的原因如下：

    • 线程的数量过少
    • 锁的粒度过大导致的锁竞争
    • 资源竞争
    • 锁范围中有大量耗时操作
    • 远程通信的对方处理缓慢
  2. 绝大多数线程出于等待状态，只有几个工作的线程，总体性能上不去。可能的原因是，系统存在关键路径，关键路径已经达到瓶颈
  3. 线程总的数量很少（有些线程池的实现是按需创建线程，可能程序中创建线程

一个例子


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83


"Thread-243" prio=1 tid=0xa58f2048 nid=0x7ac2 runnable

[0xaeedb000..0xaeedc480]

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(SocketInputStream.java:129)

at oracle.net.ns.Packet.receive(Unknown Source)

... ...

at oracle.jdbc.driver.LongRawAccessor.getBytes()

at oracle.jdbc.driver.OracleResultSetImpl.getBytes()

- locked <0x9350b0d8> (a oracle.jdbc.driver.OracleResultSetImpl)

at oracle.jdbc.driver.OracleResultSet.getBytes(O)

... ...

at org.hibernate.loader.hql.QueryLoader.list()

at org.hibernate.hql.ast.QueryTranslatorImpl.list()

... ...

at com.wes.NodeTimerOut.execute(NodeTimerOut.java:175)

at com.wes.timer.TimerTaskImpl.executeAll(TimerTaskImpl.java:707)

at com.wes.timer.TimerTaskImpl.execute(TimerTaskImpl.java:627)

- locked <0x80df8ce8> (a com.wes.timer.TimerTaskImpl)

at com.wes.threadpool.RunnableWrapper.run(RunnableWrapper.java:209)

at com.wes.threadpool.PooledExecutorEx$Worker.run()

at java.lang.Thread.run(Thread.java:595)

"Thread-248" prio=1 tid=0xa58f2048 nid=0x7ac2 runnable

[0xaeedb000..0xaeedc480]

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(SocketInputStream.java:129)

at oracle.net.ns.Packet.receive(Unknown Source)

... ...

at oracle.jdbc.driver.LongRawAccessor.getBytes()

at oracle.jdbc.driver.OracleResultSetImpl.getBytes()

- locked <0x9350b0d8> (a oracle.jdbc.driver.OracleResultSetImpl)

at oracle.jdbc.driver.OracleResultSet.getBytes(O)

... ...

at org.hibernate.loader.hql.QueryLoader.list()

at org.hibernate.hql.ast.QueryTranslatorImpl.list()

... ...

at com.wes.NodeTimerOut.execute(NodeTimerOut.java:175)

at com.wes.timer.TimerTaskImpl.executeAll(TimerTaskImpl.java:707)

at com.wes.timer.TimerTaskImpl.execute(TimerTaskImpl.java:627)

- locked <0x80df8ce8> (a com.wes.timer.TimerTaskImpl)

at com.wes.threadpool.RunnableWrapper.run(RunnableWrapper.java:209)

at com.wes.threadpool.PooledExecutorEx$Worker.run()

at java.lang.Thread.run(Thread.java:595)

... ...

"Thread-238" prio=1 tid=0xa4a84a58 nid=0x7abd in Object.wait()

[0xaec56000..0xaec57700]

at java.lang.Object.wait(Native Method)

at com.wes.collection.SimpleLinkedList.poll(SimpleLinkedList.java:104)

- locked <0x6ae67be0> (a com.wes.collection.SimpleLinkedList)

at com.wes.XADataSourceImpl.getConnection_internal(XADataSourceImpl.java:1642)

... ...

at org.hibernate.impl.SessionImpl.list()

at org.hibernate.impl.SessionImpl.find()

at com.wes.DBSessionMediatorImpl.find()

at com.wes.ResourceDBInteractorImpl.getCallBackObj()

at com.wes.NodeTimerOut.execute(NodeTimerOut.java:152)

at com.wes.timer.TimerTaskImpl.executeAll()

at com.wes.timer.TimerTaskImpl.execute(TimerTaskImpl.java:627)

- locked <0x80e08c00> (a com.facilities.timer.TimerTaskImpl)

at com.wes.threadpool.RunnableWrapper.run(RunnableWrapper.java:209)

at com.wes.threadpool.PooledExecutorEx$Worker.run()

at java.lang.Thread.run(Thread.java:595)

"Thread-233" prio=1 tid=0xa4a84a58 nid=0x7abd in Object.wait()

[0xaec56000..0xaec57700]

at java.lang.Object.wait(Native Method)

at com.wes.collection.SimpleLinkedList.poll(SimpleLinkedList.java:104)

- locked <0x6ae67be0> (a com.wes.collection.SimpleLinkedList)

at com.wes.XADataSourceImpl.getConnection_internal(XADataSourceImpl.java:1642)

... ...

at org.hibernate.impl.SessionImpl.list()

at org.hibernate.impl.SessionImpl.find()

at com.wes.DBSessionMediatorImpl.find()

at com.wes.ResourceDBInteractorImpl.getCallBackObj()

at com.wes.NodeTimerOut.execute(NodeTimerOut.java:152)

at com.wes.timer.TimerTaskImpl.executeAll()

at com.wes.timer.TimerTaskImpl.execute(TimerTaskImpl.java:627)

- locked <0x80e08c00> (a com.facilities.timer.TimerTaskImpl)

at com.wes.threadpool.RunnableWrapper.run(RunnableWrapper.java:209)

at com.wes.threadpool.PooledExecutorEx$Worker.run()

at java.lang.Thread.run(Thread.java:595)

... ...

从堆栈看，有 51 个（socket）访问，其中有 50 个是 JDBC 数据库访问。其他方法被阻塞在 java.lang.Object.wait() 方法上。

2.2.3 其他提高性能的方法

减少锁的粒度，比如 ConcurrentHashMap 的实现默认使用 16 个锁的 Array（有一个副作用：锁整个容器会很费力，可以添加一个全局锁）

2.2.4 性能调优的终结条件

性能调优总有一个终止条件，如果系统满足如下两个条件，即可终止：

  1. 算法足够优化
  2. 没有线程/资源的使用不当而导致的 CPU 利用不足

原文地址：https://www.cnblogs.com/lfs2640666960/p/9302216.html

时间： 2024-08-29 07:44:46

通过 Java 线程堆栈进行性能瓶颈分析的相关文章

Java线程池使用和分析(二) - execute()原理

相关文章目录: Java线程池使用和分析(一) Java线程池使用和分析(二) - execute()原理 execute()是 java.util.concurrent.Executor接口中唯一的方法,JDK注释中的描述是“在未来的某一时刻执行命令command”,即向线程池中提交任务,在未来某个时刻执行,提交的任务必须实现Runnable接口,该提交方式不能获取返回值.下面是对execute()方法内部原理的分析,分析前先简单介绍线程池有哪些状态,在一系列执行过程中涉及线程池状态相关的判断

java线程池框架源代码分析

相关类Executor,Executors.AbstractExecutorService.ExecutorService Executor:整个线程池运行者框架的顶层接口. 定义了一个execute方法.整个线程运行者框架的核心方法. public interface Executor { void execute(Runnable command); } ExecutorService:这是一个接口它继承自Executor,定义了shutdown.shutdownNow,awaitTermi

java线程安全问题原理性分析

1.什么是线程安全问题? 从某个线程开始访问到访问结束的整个过程,如果有一个访问对象被其他线程修改,那么对于当前线程而言就发生了线程安全问题:如果在整个访问过程中,无一对象被其他线程修改,就是线程安全的. 2.线程安全问题产生的根本原因 首先是多线程环境,即同时存在有多个操作者,单线程环境不存在线程安全问题.在单线程环境下,任何操作包括修改操作都是操作者自己发出的,操作者发出操作时不仅有明确的目的,而且意识到操作的影响. 多个操作者(线程)必须操作同一个对象,只有多个操作者同时操作一个对象,行为

【转】java线上程序排错经验2 - 线程堆栈分析

前言 在线上的程序中,我们可能经常会碰到程序卡死或者执行很慢的情况,这时候我们希望知道是代码哪里的问题,我们或许迫切希望得到代码运行到哪里了,是哪一步很慢,是否是进入了死循环,或者是否哪一段代码有问题导致程序很慢,或者出现了线程不安全的情况,或者是某些连接数或者打开文件数太多等问题,总之我们想知道程序卡在哪里了,哪块占用了大量的资源. 此时,或许通过线程堆栈的分析就能定位出问题. 如果能深入掌握堆栈分析的技术,很多问题都能迎刃而解,但是线程堆栈分析并不简单,设计到线上的排错问题,需要有一定的知识

JVM：如何分析线程堆栈

英文原文:JVM: How to analyze Thread Dump 在这篇文章里我将教会你如何分析JVM的线程堆栈以及如何从堆栈信息中找出问题的根因.在我看来线程堆栈分析技术是Java EE产品支持工程师所必须掌握的一门技术.在线程堆栈中存储的信息,通常远超出你的想象,我们可以在工作中善加利用这些信息. 我的目标是分享我过去十几年来在线程分析中积累的知识和经验.这些知识和经验是在各种版本的JVM以及各厂商的JVM供应商的深入分析中获得的,在这个过程中我也总结出大量的通用问题模板. 那么,准

基于 JVMTI 实现 Java 线程的监控（转）

随着多核 CPU 的日益普及,越来越多的 Java 应用程序使用多线程并行计算来充分发挥整个系统的性能.多线程的使用也给应用程序开发人员带来了巨大的挑战,不正确地使用多线程可能造成线程死锁或资源竞争,导致系统瘫痪.因此,需要一种运行时线程监控工具来帮助开发人员诊断和跟踪 Java 线程状态的切换.JDK 1.5 及其后续版本提供了监控虚拟机运行状态的接口 JVMTI.本文深入分析了 JVM 中的 Java 线程模型,设计了用于监控线程状态切换的模型,并基于 JVMTI 实现了对 Java 线程切

Java 线程转储

软件维护是一个枯燥而又有挑战性的工作.只要软件功能符合预期,那么这个工作就是好的.设想一个这样的情景,你的电话半夜也一直在响(这不是一个令人愉快的感受,是吧?)任何软件系统,无论它当初是被设计的多好,也无论它经历了怎样的质量测试,仍然是有可能出现运行时性能问题.原因可能是内部功能限制或者外部环境影响.软件系统是在某种假定的情景和先入为主的观念之上被建立的.然而,当他们实际运行时,这些假定的情况可能是错误的,由此就会引起系统故障.企业的J2EE系统通常拥有庞大的用户基数,并且涉及多种系统间的交互,

Java线程中的同步

1.对象与锁 每一个Object类及其子类的实例都拥有一个锁.其中,标量类型int,float等不是对象类型,但是标量类型可以通过其包装类来作为锁.单独的成员变量是不能被标明为同步的.锁只能用在使用了这些变量的方法上.成员变量可以被声明为volatile,这种方式会影响该变量的原子性,可见性以及排序性.类似的,持有标量变量元素的数组对象拥有锁,但是其中的标量元素却不拥有锁.(也就是说,没有办法将数组成员声明为volatile类型的).如果锁住了一个数组并不代表其数组成员都可以被原子的锁定.也没有

Linux下Java线程详细监控和其dump的分析使用----分析Java性能瓶颈

这里对linux下.sun(oracle) JDK的线程资源占用问题的查找步骤做一个小结: linux环境下,当发现java进程占用CPU资源很高,且又要想更进一步查出哪一个java线程占用了CPU资源时,按照以下步骤进行查找: (一):通过[top -p 12377 -H] 查看java进程的有哪些线程的运行情况:       和通过[jstack 12377 > stack.log]生成Java线程的dump详细信息: 先用top命令找出占用资源厉害的java进程id,如图:# top 如上