前言
分布式系统的性能指标，广义来讲，可能有多个方面，比如吞吐量（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%、内存泄漏、死锁、线程频繁切换问题。分析问题我们需要做好两件事，第一，掌握基本的原理，第二，借助好工具。本文也列举了分析问题的常用工具和命令，希望对你解决问题有所帮助。当然真正的线上环境可能十分复杂，并没有模拟的环境那么简单，但是原理是一样的，问题的表现也是类似的，我们重点抓住原理，活学活用，相信复杂的线上问题也可以顺利解决。
觉得文章写的还不错的，麻烦老铁点赞+关注支持一下，后期会不断更新技术好文，不迷路
