前言
分布式系统的性能指标，广义来讲，可能有多个方面，比如吞吐量（TPS）、高可用（几个9）、低延时（RT）、客户体验（PV/UV）、数据一致性、可扩展性、容错性等。狭义来讲，我们常用业务吞吐量（TPS）来表达系统性能。即：在满足一定客户体验前提下，在一定机器资源环境下，系统所能够承载的最大业务处理能力，通常用每秒处理的事务数TPS来表示。
而除了在出现问题的时候去进行解决，更多的是防患于未然，在平时的开发过程中稍微的注意一下，可能会避免后期很多的事情
今天文章主要从两个方面讲解：性能优化的50个细节和如何定位性能问题
性能优化的50个细节
1. 尽量在合适的场合使用单例
使用单例可以减轻加载的负担，缩短加载的时间，提高加载的效率，但并不是所在地方都适用于单例
简单来说，单例主要适用于以下三个方面：
- 控制资源的使用，通过线程同步来控制资源的并发访问；
- 控制实例的产生，以达到节约资源的目的；
- 控制数据共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。
2. 尽量避免随意使用静态变量
当某个对象被定义为static变量所引用，那么GC通常是不会回收这个对象所占有的内存，如:
publicclassA{
privatestaticB b =newB();
}
此时静态变量 b 的生命周期与A类同步，如果A类不会卸载，那么b对象会常驻内存，直到程序终止。
3. 尽量避免过多过常地创建Java对象
尽量避免在经常调用的方法，循环中new对象，由于系统不仅要花费时间来创建对象，而且还要花时间对这些对象进行垃圾回收和处理
在我们可以控制的范围内，最大限度地重用对象，最好能用基本的数据类型或数组来替代对象。
4. 尽量使用final修饰符
带有final修饰符的类是不可派生的。在JAVA核心API中，有许多应用final的例子，例如java、lang、String，为String类指定final防止了使用者覆盖length()方法。
另外，如果一个类是final的，则该类所有方法都是final的。java编译器会寻找机会内联（inline）所有的final方法（这和具体的编译器实现有关），此举能够使性能平均提高50%。
如：让访问实例内变量的getter/setter方法变成”final：简单的getter/setter方法应该被置成final，这会告诉编译器，这个方法不会被重载，所以，可以变成”inlined”,例子：
classMAF{
publicvoidsetSize(intsize){
_size = size;
}
privateint_size;
}
更正
classDAF_fixed{
finalpublicvoidsetSize(intsize){
_size = size;
}
privateint_size;
}
5. 尽量使用局部变量
调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快；其他变量，如静态变量、实例变量等，都在堆（Heap）中创建，速度较慢。
6. 尽量处理好包装类型和基本类型两者的使用场所
虽然包装类型和基本类型在使用过程中是可以相互转换，但它们两者所产生的内存区域是完全不同的
基本类型数据产生和处理都在栈中处理，包装类型是对象，是在堆中产生实例。在集合类对象，有对象方面需要的处理适用包装类型，其他的处理提倡使用基本类型。
7. 慎用synchronized，尽量减小synchronize的方法
都知道，实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。
synchronize方法被调用时，直接会把当前对象锁了，在方法执行完之前其他线程无法调用当前对象的其他方法。
所以，synchronize的方法尽量减小，并且应尽量使用方法同步代替代码块同步。
9. 尽量不要使用finalize方法
实际上，将资源清理放在finalize方法中完成是非常不好的选择
由于GC的工作量很大，尤其是回收Young代内存时，大都会引起应用程序暂停，所以再选择使用finalize方法进行资源清理，会导致GC负担更大，程序运行效率更差。
10. 尽量使用基本数据类型代替对象
Stringstr="hello";
上面这种方式会创建一个“hello”字符串，而且JVM的字符缓存池还会缓存这个字符串；
Stringstr=newString("hello");
此时程序除创建字符串外，str所引用的String对象底层还包含一个char[]数组，这个char[]数组依次存放了h,e,l,l,o
11. 多线程在未发生线程安全前提下应尽量使用HashMap、ArrayList
HashTable、Vector等使用了同步机制，降低了性能。
12. 尽量合理的创建HashMap
当你要创建一个比较大的hashMap时，充分利用这个构造函数
public HashMap(int initialCapacity, float loadFactor);
避免HashMap多次进行了hash重构,扩容是一件很耗费性能的事
在默认中initialCapacity只有16，而loadFactor是 0.75，需要多大的容量，你最好能准确的估计你所需要的最佳大小，同样的Hashtable，Vectors也是一样的道理。
13. 尽量减少对变量的重复计算
如：
for(inti=0;i<list.size();i++)
应该改为：
for(inti=0,len=list.size();i<len;i++)
并且在循环中应该避免使用复杂的表达式，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。
14. 尽量避免不必要的创建
如：
A a =newA();
if(i==1){
list.add(a);
}
应该改为：
if(i==1){
A a =newA();
list.add(a);
}
15. 尽量在finally块中释放资源
程序中使用到的资源应当被释放，以避免资源泄漏，这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。
16. 尽量使用移位来代替'a/b'的操作
"/"是一个代价很高的操作，使用移位的操作将会更快和更有效
如：
intnum = a /4; intnum = a /8;
应该改为：
intnum = a >>2; intnum = a >>3;
但注意的是使用移位应添加注释，因为移位操作不直观，比较难理解。
17.尽量使用移位来代替'a*b'的操作
同样的，对于'*'操作，使用移位的操作将会更快和更有效
如：
intnum = a *4; intnum = a *8;
应该改为：
intnum = a <<2; intnum = a <<3;
18. 尽量确定StringBuffer的容量
StringBuffer 的构造器会创建一个默认大小（通常是16）的字符数组。
在使用中，如果超出这个大小，就会重新分配内存，创建一个更大的数组，并将原先的数组复制过来，再丢弃旧的数组。
在大多数情况下，你可以在创建 StringBuffer的时候指定大小，这样就避免了在容量不够的时候自动增长，以提高性能。如：
StringBufferbuffer=newStringBuffer(1000);
19. 尽量早释放无用对象的引用
大部分时，方法局部引用变量所引用的对象会随着方法结束而变成垃圾，因此，大部分时候程序无需将局部，引用变量显式设为null。例如：
Java代码
Publicvoidtest(){
Objectobj =newObject();
……
Obj =null;
}
上面这个就没必要了，随着方法test()的执行完成，程序中obj引用变量的作用域就结束了。
但是如果是改成下面：
Java代码
Publicvoidtest(){
Objectobj =newObject();
……
Obj =null;
//执行耗时，耗内存操作；或调用耗时，耗内存的方法
……
}
这时候就有必要将obj赋值为null，可以尽早的释放对Object对象的引用。
20. 尽量避免使用二维数组
二维数据占用的内存空间比一维数据多得多，大概10倍以上。
21. 尽量避免使用split
除非是必须的，否则应该避免使用split，split由于支持正则表达式，所以效率比较低
如果是频繁的几十，几百万的调用将会耗费大量资源，如果确实需要频繁的调用split，可以考虑使用apache的StringUtils.split(string,char)，频繁split的可以缓存结果
22. ArrayList & LinkedList
一个是线性表，一个是链表，一句话，随机查询尽量使用ArrayList，ArrayList优于LinkedList，LinkedList还要移动指针，添加删除的操作LinkedList优于ArrayList，ArrayList还要移动数据
不过这是理论性分析，事实未必如此，重要的是理解好2者的数据结构，对症下药。
23. 尽量使用System.arraycopy ()代替通过来循环复制数组
System.arraycopy() 要比通过循环来复制数组快的多。
24. 尽量缓存经常使用的对象
尽可能将经常使用的对象进行缓存，可以使用数组，或HashMap的容器来进行缓存，但这种方式可能导致系统占用过多的缓存，性能下降
推荐可以使用一些第三方的开源工具，如EhCache，Oscache进行缓存，他们基本都实现了FIFO/FLU等缓存算法。
25. 尽量避免非常大的内存分配
有时候问题不是由当时的堆状态造成的，而是因为分配失败造成的。分配的内存块都必须是连续的，而随着堆越来越满，找到较大的连续块越来越困难。
26. 慎用异常
当创建一个异常时，需要收集一个栈跟踪(stack track)，这个栈跟踪用于描述异常是在何处创建的。
构建这些栈跟踪时需要为运行时栈做一份快照，正是这一部分开销很大。
当需要创建一个 Exception 时，JVM 不得不说：先别动，我想就您现在的样子存一份快照，所以暂时停止入栈和出栈操作。栈跟踪不只包含运行时栈中的一两个元素，而是包含这个栈中的每一个元素。
如果您创建一个 Exception ，就得付出代价，好在捕获异常开销不大，因此可以使用 try-catch 将核心内容包起来。
从技术上讲，你甚至可以随意地抛出异常，而不用花费很大的代价。招致性能损失的并不是 throw 操作——尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。
真正要花代价的是创建异常，幸运的是，好的编程习惯已教会我们，不应该不管三七二十一就抛出异常。异常是为异常的情况而设计的，使用时也应该牢记这一原则。
27. 尽量重用对象
特别是String对象的使用中，出现字符串连接情况时应使用StringBuffer代替，由于系统不仅要花时间生成对象，以后可能还需要花时间对这些对象进行垃圾回收和处理。因此生成过多的对象将会给程序的性能带来很大的影响。
28. 不要重复初始化变量
默认情况下，调用类的构造函数时，java会把变量初始化成确定的值，所有的对象被设置成null，整数变量设置成0，float和double变量设置成0.0，逻辑值设置成false。
当一个类从另一个类派生时，这一点尤其应该注意，因为用new关键字创建一个对象时，构造函数链中的所有构造函数都会被自动调用。
这里有个注意，给成员变量设置初始值但需要调用其他方法的时候，最好放在一个方法。比如initXXX()中，因为直接调用某方法赋值可能会因为类尚未初始化而抛空指针异常，如：public int state = this.getState()。
29. 在java+Oracle的应用系统开发中，java中内嵌的SQL语言应尽量使用大写形式，以减少Oracle解析器的解析负担。
30. 在java编程过程中，进行数据库连接，I/O流操作，在使用完毕后，及时关闭以释放资源。因为对这些大对象的操作会造成系统大的开销。
31. 过分的创建对象会消耗系统的大量内存，严重时，会导致内存泄漏
因此，保证过期的对象的及时回收具有重要意义。JVM的GC并非十分智能，因此建议在对象使用完毕后，手动设置成null。
32. 在使用同步机制时，应尽量使用方法同步代替代码块同步。
33. 不要在循环中使用Try/Catch语句，应把Try/Catch放在循环最外层
Error是获取系统错误的类，或者说是虚拟机错误的类。不是所有的错误Exception都能获取到的，虚拟机报错Exception就获取不到，必须用Error获取。
34. 通过StringBuffer的构造函数来设定它的初始化容量，可以明显提升性能
StringBuffer的默认容量为16，当StringBuffer的容量达到最大容量时，它会将自身容量增加到当前的2倍+2，也就是2*n+2。
无论何时，只要StringBuffer到达它的最大容量，它就不得不创建一个新的对象数组，然后复制旧的对象数组，这会浪费很多时间。
所以给StringBuffer设置一个合理的初始化容量值，是很有必要的！
35. 合理使用java.util.Vector
Vector与StringBuffer类似，每次扩展容量时，所有现有元素都要赋值到新的存储空间中。
Vector的默认存储能力为10个元素，扩容加倍
vector.add(index,obj) 这个方法可以将元素obj插入到index位置，但index以及之后的元素依次都要向下移动一个位置（将其索引加 1）。除非必要，否则对性能不利。
同样规则适用于remove(int index)方法，移除此向量中指定位置的元素。将所有后续元素左移（将其索引减 1）。返回此向量中移除的元素。
所以删除vector最后一个元素要比删除第1个元素开销低很多。删除所有元素最好用removeAllElements()方法。
如果要删除vector里的一个元素可以使用 vector.remove(obj)；而不必自己检索元素位置，再删除，如int index = indexOf（obj）;vector.remove(index)。
38. 不用new关键字创建对象的实例
用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用。
但如果一个对象实现了Cloneable接口，我们可以调用它的clone()方法。clone()方法不会调用任何类构造函数。
下面是Factory模式的一个典型实现：
publicstaticCreditgetNewCredit(){
returnnewCredit();
}
改进后的代码使用clone()方法：
privatestaticCredit BaseCredit =newCredit();
publicstaticCredit getNewCredit() {
return(Credit)BaseCredit.clone();
}
39. 不要将数组声明为：public static final
40. HaspMap的遍历：
Map<String,String[]> paraMap =newHashMap<String,String[]>();
for(Entry<String,String[]> entry : paraMap.entrySet()) {
StringappFieldDefId = entry.getKey();
String[] values = entry.getValue();
}
利用散列值取出相应的Entry做比较得到结果，取得entry的值之后直接取key和value。
41. array(数组)和ArrayList的使用
array 数组效率最高，但容量固定，无法动态改变，ArrayList容量可以动态增长，但牺牲了效率。
42. 单线程应尽量使用 HashMap, ArrayList,除非必要，否则不推荐使用HashTable,Vector，它们使用了同步机制，而降低了性能。
43. StringBuffer,StringBuilder的区别在于：java.lang.StringBuffer 线程安全的可变字符序列。一个类似于String的字符串缓冲区，但不能修改。
StringBuilder与该类相比，通常应该优先使用StringBuilder类，因为它支持所有相同的操作，但由于它不执行同步，所以速度更快。
为了获得更好的性能，在构造StringBuffer或StringBuilder时应尽量指定它的容量。当然如果不超过16个字符时就不用了。
相同情况下，使用StringBuilder比使用StringBuffer仅能获得10%~15%的性能提升，但却要冒多线程不安全的风险。综合考虑还是建议使用StringBuffer。
44. 尽量使用基本数据类型代替对象。
45. 使用具体类比使用接口效率高，但结构弹性降低了，但现代IDE都可以解决这个问题。
46. 考虑使用静态方法，如果你没有必要去访问对象的外部，那么就使你的方法成为静态方法。它会被更快地调用，因为它不需要一个虚拟函数导向表。
这同时也是一个很好的实践，因为它告诉你如何区分方法的性质，调用这个方法不会改变对象的状态。
47. 应尽可能避免使用内在的GET,SET方法。
48.避免枚举，浮点数的使用。
以下举几个实用优化的例子：
一、避免在循环条件中使用复杂表达式
在不做编译优化的情况下，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。
例子：
importjava.util.Vector;
classCEL{
voidmethod(Vectorvector){
for(inti =0; i <vector.size (); i++)// Violation
// ...
}
}
更正：
classCEL_fixed{
voidmethod(Vectorvector){
intsize =vector.size ();
for(inti =0; i < size; i++)
// ...
}
}
二、为'Vectors' 和 'Hashtables'定义初始大小
JVM为Vector扩充大小的时候需要重新创建一个更大的数组，将原原先数组中的内容复制过来，最后，原先的数组再被回收。可见Vector容量的扩大是一个颇费时间的事。
通常，默认的10个元素大小是不够的。你最好能准确的估计你所需要的最佳大小。例子：
importjava.util.Vector;
publicclassDIC{
publicvoidaddObjects(Object[] o){
// if length > 10, Vector needs to expand
for(inti =0; i< o.length;i++) {
v.add(o);// capacity before it can add more elements.
}
}
publicVector v =newVector();// no initialCapacity.
}
更正：
自己设定初始大小。
publicVector v =newVector(20); publicHashtable hash =newHashtable(10);
三、在finally块中关闭Stream
程序中使用到的资源应当被释放，以避免资源泄漏。这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。
四、使用'System.arraycopy ()'代替通过来循环复制数组
例子：
publicclassIRB{
voidmethod(){
int[] array1 =newint[100];
for(inti =0; i < array1.length; i++) {
array1 [i] = i;
}
int[] array2 =newint[100];
for(inti =0; i < array2.length; i++) {
array2 [i] = array1 [i];// Violation
}
}
}
更正：
publicclassIRB{
voidmethod(){
int[] array1 =newint[100];
for(inti =0; i < array1.length; i++) {
array1 [i] = i;
}
int[] array2 =newint[100];
System.arraycopy(array1,0, array2,0,100);
}
}
五、让访问实例内变量的getter/setter方法变成”final”
简单的getter/setter方法应该被置成final，这会告诉编译器，这个方法不会被重载，所以，可以变成”inlined”,例子：
classMAF{
publicvoidsetSize(intsize){
_size = size;
}
privateint_size;
}
更正：
classDAF_fixed{
finalpublicvoidsetSize(intsize){
_size = size;
}
privateint_size;
}
六、对于常量字符串，用'String' 代替 'StringBuffer'
常量字符串并不需要动态改变长度。
例子：
publicclassUSC{
Stringmethod(){
StringBuffer s =newStringBuffer ("Hello");
String t = s +"World!";
returnt;
}
}
更正：把StringBuffer换成String，如果确定这个String不会再变的话，这将会减少运行开销提高性能。
七、在字符串相加的时候，使用 ' ' 代替 " "，如果该字符串只有一个字符的话
例子：
publicclassSTR{
publicvoidmethod(String s){
Stringstring= s +"d"// violation.
string="abc"+"d"// violation.
}
}
publicclassSTR{
publicvoidmethod(String s){
Stringstring= s +"d"// violation.
string="abc"+"d"// violation.
}
}
更正：
将一个字符的字符串替换成' '
publicclassSTR{
publicvoidmethod(String s){
Stringstring= s +'d'
string="abc"+'d'
}
}
以上仅是Java方面编程时的性能优化，性能优化大部分都是在时间、效率、代码结构层次等方面的权衡，各有利弊
如何定位性能问题
接下来就是如何去定位性能问题了，只有准确定位了，才能具体的去进行解决啊，但是其实大家都知道，性能出现问题其实真的不算多，就像一个读者说的，ThreadLocal出现内存泄漏，我至今没有遇到过，其实包括笔者自己遇到的性能问题也不多，但是要居安思危，在平时准备好，当问题出现时才不会出现问题，我们模拟下常见的几个Java性能故障，来学习怎么去分析和定位
既然是定位问题，肯定是需要借助工具，所以肯定需要提前学习一些性能调优的工具
top命令
top命令是我们最常用的Linux命令之一，它可以实时的显示当前正在执行的进程的CPU使用率，内存使用率等系统信息。top -Hp pid 可以查看线程的系统资源使用情况。
vmstat命令
vmstat是一个指定周期和采集次数的虚拟内存检测工具，可以统计内存，CPU，swap的使用情况，它还有一个重要的常用功能，用来观察进程的上下文切换。字段说明如下:
- r: 运行队列中进程数量（当数量大于CPU核数表示有阻塞的线程）
- b: 等待IO的进程数量
- swpd: 使用虚拟内存大小
- free: 空闲物理内存大小
- buff: 用作缓冲的内存大小(内存和硬盘的缓冲区)
- cache: 用作缓存的内存大小（CPU和内存之间的缓冲区）
- si: 每秒从交换区写到内存的大小，由磁盘调入内存
- so: 每秒写入交换区的内存大小，由内存调入磁盘
- bi: 每秒读取的块数
- bo: 每秒写入的块数
- in: 每秒中断数，包括时钟中断。
- cs: 每秒上下文切换数。
- us: 用户进程执行时间百分比(user time)
- sy: 内核系统进程执行时间百分比(system time)
- wa: IO等待时间百分比
- id: 空闲时间百分比
pidstat命令
pidstat 是 Sysstat 中的一个组件，也是一款功能强大的性能监测工具，top 和 vmstat 两个命令都是监测进程的内存、CPU 以及 I/O 使用情况，而 pidstat 命令可以检测到线程级别的。pidstat命令线程切换字段说明如下：
- UID ：被监控任务的真实用户ID。
- TGID ：线程组ID。
- TID：线程ID。
- cswch/s：主动切换上下文次数，这里是因为资源阻塞而切换线程，比如锁等待等情况。
- nvcswch/s：被动切换上下文次数，这里指CPU调度切换了线程。
jstack命令
jstack是JDK工具命令，它是一种线程堆栈分析工具，最常用的功能就是使用 jstack pid 命令查看线程的堆栈信息，也经常用来排除死锁情况。
jstat 命令
它可以检测Java程序运行的实时情况，包括堆内存信息和垃圾回收信息，我们常常用来查看程序垃圾回收情况。常用的命令是jstat -gc pid。信息字段说明如下：
- S0C：年轻代中 To Survivor 的容量（单位 KB）；
- S1C：年轻代中 From Survivor 的容量（单位 KB）；
- S0U：年轻代中 To Survivor 目前已使用空间（单位 KB）；
- S1U：年轻代中 From Survivor 目前已使用空间（单位 KB）；
- EC：年轻代中 Eden 的容量（单位 KB）；
- EU：年轻代中 Eden 目前已使用空间（单位 KB）；
- OC：老年代的容量（单位 KB）；
- OU：老年代目前已使用空间（单位 KB）；
- MC：元空间的容量（单位 KB）；
- MU：元空间目前已使用空间（单位 KB）；
- YGC：从应用程序启动到采样时年轻代中 gc 次数；
- YGCT：从应用程序启动到采样时年轻代中 gc 所用时间 (s)；
- FGC：从应用程序启动到采样时 老年代（Full Gc）gc 次数；
- FGCT：从应用程序启动到采样时 老年代代（Full Gc）gc 所用时间 (s)；
- GCT：从应用程序启动到采样时 gc 用的总时间 (s)。
jmap命令
jmap也是JDK工具命令，它可以查看堆内存的初始化信息以及堆内存的使用情况，还可以生成dump文件来进行详细分析。查看堆内存情况命令jmap -heap pid。
mat内存工具
MAT(Memory Analyzer Tool)工具是eclipse的一个插件(MAT也可以单独使用)，它分析大内存的dump文件时，可以非常直观的看到各个对象在堆空间中所占用的内存大小、类实例数量、对象引用关系、利用OQL对象查询，以及可以很方便的找出对象GC Roots的相关信息。下载地址可以点击这里
模拟环境准备
基础环境jdk1.8，采用SpringBoot框架来写几个接口来触发模拟场景，首先是模拟CPU占满情况
CPU占满
模拟CPU占满还是比较简单，直接写一个死循环计算消耗CPU即可。
/**
* 模拟CPU占满
*/
@GetMapping("/cpu/loop")
public void testCPULoop() throws InterruptedException {
System.out.println("请求cpu死循环");
Thread.currentThread().setName("loop-thread-cpu");
int num = 0;
while (true) {
num++;
if (num == Integer.MAX_VALUE) {
System.out.println("reset");
}
num = 0;
}
}
复制代码
请求接口地址测试curl localhost:8080/cpu/loop,发现CPU立马飙升到100%
通过执行top -Hp 32805 查看Java线程情况
执行 printf '%x' 32826 获取16进制的线程id，用于dump信息查询，结果为 803a。最后我们执行jstack 32805 |grep -A 20 803a来查看下详细的dump信息。
这里dump信息直接定位出了问题方法以及代码行，这就定位出了CPU占满的问题。
内存泄露
模拟内存泄漏借助了ThreadLocal对象来完成，ThreadLocal是一个线程私有变量，可以绑定到线程上，在整个线程的生命周期都会存在，但是由于ThreadLocal的特殊性，ThreadLocal是基于ThreadLocalMap实现的，ThreadLocalMap的Entry继承WeakReference，而Entry的Key是WeakReference的封装，换句话说Key就是弱引用，弱引用在下次GC之后就会被回收，如果ThreadLocal在set之后不进行后续的操作，因为GC会把Key清除掉，但是Value由于线程还在存活，所以Value一直不会被回收，最后就会发生内存泄漏。
/**
* 模拟内存泄漏
*/
@GetMapping(value = "/memory/leak")
public String leak() {
System.out.println("模拟内存泄漏");
ThreadLocal<Byte[]> localVariable = new ThreadLocal<Byte[]>();
localVariable.set(new Byte[4096 * 1024]);// 为线程添加变量
return "ok";
}
复制代码
我们给启动加上堆内存大小限制，同时设置内存溢出的时候输出堆栈快照并输出日志。
java -jar -Xms500m -Xmx500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/tmp/heaplog.log analysis-demo-0.0.1-SNAPSHOT.jar
启动成功后我们循环执行100次,for i in {1..500}; do curl localhost:8080/memory/leak;done,还没执行完毕，系统已经返回500错误了。查看系统日志出现了如下异常：
java.lang.OutOfMemoryError: Java heap space 复制代码
我们用jstat -gc pid 命令来看看程序的GC情况。
很明显，内存溢出了，堆内存经过45次 Full Gc 之后都没释放出可用内存，这说明当前堆内存中的对象都是存活的，有GC Roots引用，无法回收。那是什么原因导致内存溢出呢？是不是我只要加大内存就行了呢？如果是普通的内存溢出也许扩大内存就行了，但是如果是内存泄漏的话，扩大的内存不一会就会被占满，所以我们还需要确定是不是内存泄漏。我们之前保存了堆 Dump 文件，这个时候借助我们的MAT工具来分析下。导入工具选择Leak Suspects Report，工具直接就会给你列出问题报告。
这里已经列出了可疑的4个内存泄漏问题，我们点击其中一个查看详情。
这里已经指出了内存被线程占用了接近50M的内存，占用的对象就是ThreadLocal。如果想详细的通过手动去分析的话，可以点击Histogram,查看最大的对象占用是谁，然后再分析它的引用关系，即可确定是谁导致的内存溢出。
上图发现占用内存最大的对象是一个Byte数组，我们看看它到底被那个GC Root引用导致没有被回收。按照上图红框操作指引，结果如下图：
我们发现Byte数组是被线程对象引用的，图中也标明，Byte数组对象的GC Root是线程，所以它是不会被回收的，展开详细信息查看，我们发现最终的内存占用对象是被ThreadLocal对象占据了。这也和MAT工具自动帮我们分析的结果一致。
死锁
死锁会导致耗尽线程资源，占用内存，表现就是内存占用升高，CPU不一定会飙升(看场景决定)，如果是直接new线程，会导致JVM内存被耗尽，报无法创建线程的错误，这也是体现了使用线程池的好处。
ExecutorService service = new ThreadPoolExecutor(4, 10,
0, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(1024),
Executors.defaultThreadFactory(),
new ThreadPoolExecutor.AbortPolicy());
/**
* 模拟死锁
*/
@GetMapping("/cpu/test")
public String testCPU() throws InterruptedException {
System.out.println("请求cpu");
Object lock1 = new Object();
Object lock2 = new Object();
service.submit(new DeadLockThread(lock1, lock2), "deadLookThread-" + new Random().nextInt());
service.submit(new DeadLockThread(lock2, lock1), "deadLookThread-" + new Random().nextInt());
return "ok";
}
public class DeadLockThread implements Runnable {
private Object lock1;
private Object lock2;
public DeadLockThread(Object lock1, Object lock2) {
this.lock1 = lock1;
this.lock2 = lock2;
}
@Override
public void run() {
synchronized (lock2) {
System.out.println(Thread.currentThread().getName()+"get lock2 and wait lock1");
try {
TimeUnit.MILLISECONDS.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lock1) {
System.out.println(Thread.currentThread().getName()+"get lock1 and lock2 ");
}
}
}
}
复制代码
我们循环请求接口2000次，发现不一会系统就出现了日志错误，线程池和队列都满了,由于我选择的当队列满了就拒绝的策略，所以系统直接抛出异常。
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@2760298 rejected from java.util.concurrent.ThreadPoolExecutor@7ea7cd51[Running, pool size = 10, active threads = 10, queued tasks = 1024, completed tasks = 846] 复制代码
通过ps -ef|grep java命令找出 Java 进程 pid，执行jstack pid 即可出现java线程堆栈信息，这里发现了5个死锁，我们只列出其中一个，很明显线程pool-1-thread-2锁住了0x00000000f8387d88等待0x00000000f8387d98锁，线程pool-1-thread-1锁住了0x00000000f8387d98等待锁0x00000000f8387d88,这就产生了死锁。
Java stack information for the threads listed above:
===================================================
"pool-1-thread-2":
at top.luozhou.analysisdemo.controller.DeadLockThread2.run(DeadLockThread.java:30)
- waiting to lock <0x00000000f8387d98> (a java.lang.Object)
- locked <0x00000000f8387d88> (a java.lang.Object)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"pool-1-thread-1":
at top.luozhou.analysisdemo.controller.DeadLockThread1.run(DeadLockThread.java:30)
- waiting to lock <0x00000000f8387d88> (a java.lang.Object)
- locked <0x00000000f8387d98> (a java.lang.Object)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Found 5 deadlocks.
复制代码
线程频繁切换
上下文切换会导致将大量CPU时间浪费在寄存器、内核栈以及虚拟内存的保存和恢复上，导致系统整体性能下降。当你发现系统的性能出现明显的下降时候，需要考虑是否发生了大量的线程上下文切换。
@GetMapping(value = "/thread/swap")
public String theadSwap(int num) {
System.out.println("模拟线程切换");
for (int i = 0; i < num; i++) {
new Thread(new ThreadSwap1(new AtomicInteger(0)),"thread-swap"+i).start();
}
return "ok";
}
public class ThreadSwap1 implements Runnable {
private AtomicInteger integer;
public ThreadSwap1(AtomicInteger integer) {
this.integer = integer;
}
@Override
public void run() {
while (true) {
integer.addAndGet(1);
Thread.yield(); //让出CPU资源
}
}
}
复制代码
这里我创建多个线程去执行基础的原子+1操作，然后让出 CPU 资源，理论上 CPU 就会去调度别的线程，我们请求接口创建100个线程看看效果如何，curl localhost:8080/thread/swap?num=100。接口请求成功后，我们执行`vmstat 1 10，表示每1秒打印一次，打印10次，线程切换采集结果如下：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 101 0 128000 878384 908 468684 0 0 0 0 4071 8110498 14 86 0 0 0 100 0 128000 878384 908 468684 0 0 0 0 4065 8312463 15 85 0 0 0 100 0 128000 878384 908 468684 0 0 0 0 4107 8207718 14 87 0 0 0 100 0 128000 878384 908 468684 0 0 0 0 4083 8410174 14 86 0 0 0 100 0 128000 878384 908 468684 0 0 0 0 4083 8264377 14 86 0 0 0 100 0 128000 878384 908 468688 0 0 0 108 4182 8346826 14 86 0 0 0 复制代码
这里我们关注4个指标，r,cs,us,sy。
r=100,说明等待的进程数量是100，线程有阻塞。
cs=800多万，说明每秒上下文切换了800多万次，这个数字相当大了。
us=14，说明用户态占用了14%的CPU时间片去处理逻辑。
sy=86，说明内核态占用了86%的CPU，这里明显就是做上下文切换工作了。
我们通过top命令以及top -Hp pid查看进程和线程CPU情况，发现Java线程CPU占满了，但是线程CPU使用情况很平均，没有某一个线程把CPU吃满的情况。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 87093 root 20 0 4194788 299056 13252 S 399.7 16.1 65:34.67 java 复制代码
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 87189 root 20 0 4194788 299056 13252 R 4.7 16.1 0:41.11 java 87129 root 20 0 4194788 299056 13252 R 4.3 16.1 0:41.14 java 87130 root 20 0 4194788 299056 13252 R 4.3 16.1 0:40.51 java 87133 root 20 0 4194788 299056 13252 R 4.3 16.1 0:40.59 java 87134 root 20 0 4194788 299056 13252 R 4.3 16.1 0:40.95 java 复制代码
结合上面用户态CPU只使用了14%，内核态CPU占用了86%，可以基本判断是Java程序线程上下文切换导致性能问题。
我们使用pidstat命令来看看Java进程内部的线程切换数据，执行pidstat -p 87093 -w 1 10,采集数据如下：
11:04:30 PM UID TGID TID cswch/s nvcswch/s Command 11:04:30 PM 0 - 87128 0.00 16.07 |__java 11:04:30 PM 0 - 87129 0.00 15.60 |__java 11:04:30 PM 0 - 87130 0.00 15.54 |__java 11:04:30 PM 0 - 87131 0.00 15.60 |__java 11:04:30 PM 0 - 87132 0.00 15.43 |__java 11:04:30 PM 0 - 87133 0.00 16.02 |__java 11:04:30 PM 0 - 87134 0.00 15.66 |__java 11:04:30 PM 0 - 87135 0.00 15.23 |__java 11:04:30 PM 0 - 87136 0.00 15.33 |__java 11:04:30 PM 0 - 87137 0.00 16.04 |__java 复制代码
根据上面采集的信息，我们知道Java的线程每秒切换15次左右，正常情况下，应该是个位数或者小数。结合这些信息我们可以断定Java线程开启过多，导致频繁上下文切换，从而影响了整体性能。
为什么系统的上下文切换是每秒800多万，而 Java 进程中的某一个线程切换才15次左右？
系统上下文切换分为三种情况:
1、多任务：在多任务环境中，一个进程被切换出CPU，运行另外一个进程，这里会发生上下文切换。
2、中断处理：发生中断时，硬件会切换上下文。在vmstat命令中是in
3、用户和内核模式切换：当操作系统中需要在用户模式和内核模式之间进行转换时，需要进行上下文切换,比如进行系统函数调用。
Linux 为每个 CPU 维护了一个就绪队列，将活跃进程按照优先级和等待 CPU 的时间排序，然后选择最需要 CPU 的进程，也就是优先级最高和等待 CPU 时间最长的进程来运行。也就是vmstat命令中的r。
那么，进程在什么时候才会被调度到 CPU 上运行呢？
- 进程执行完终止了，它之前使用的 CPU 会释放出来，这时再从就绪队列中拿一个新的进程来运行
- 为了保证所有进程可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片被轮流分配给各个进程。当某个进程时间片耗尽了就会被系统挂起，切换到其它等待 CPU 的进程运行。
- 进程在系统资源不足时，要等待资源满足后才可以运行，这时进程也会被挂起，并由系统调度其它进程运行。
- 当进程通过睡眠函数 sleep 主动挂起时，也会重新调度。
- 当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行。
- 发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序。
结合我们之前的内容分析，阻塞的就绪队列是100左右，而我们的CPU只有4核，这部分原因造成的上下文切换就可能会相当高，再加上中断次数是4000左右和系统的函数调用等，整个系统的上下文切换到800万也不足为奇了。Java内部的线程切换才15次，是因为线程使用Thread.yield()来让出CPU资源，但是CPU有可能继续调度该线程，这个时候线程之间并没有切换，这也是为什么内部的某个线程切换次数并不是非常大的原因。
总结
本文模拟了常见的性能问题场景，分析了如何定位CPU100%、内存泄漏、死锁、线程频繁切换问题。分析问题我们需要做好两件事，第一，掌握基本的原理，第二，借助好工具。本文也列举了分析问题的常用工具和命令，希望对你解决问题有所帮助。当然真正的线上环境可能十分复杂，并没有模拟的环境那么简单，但是原理是一样的，问题的表现也是类似的，我们重点抓住原理，活学活用，相信复杂的线上问题也可以顺利解决。
觉得文章写的还不错的，麻烦老铁点赞+关注支持一下，后期会不断更新技术好文，不迷路
需要更多资料的，关注公众号：Java架构师联盟，每日更细技术好文
转载：https://blog.csdn.net/weixin_42864905/article/details/105963008