常用命令
jps：查看正在运行的Java进程
jstat：查看JVM统计信息
jinfo：实时查看和修改JVM配置卷数
jmap：导出内存映像文件&内存使用情况
jstack：打印JVM中线程快照
jcmd：多功能命令行
jstatd：远程主机信息收集
jhat：JDK自带堆分析工具
案例1：堆溢出
/**
* 案例1：模拟线上环境OOM
*/
@RequestMapping("/add")
public void addObject(){
System.err.println("add"+peopleSevice);
ArrayList<People> people = new ArrayList<>();
while (true){
people.add(new People());
}
}参数配置
-XX:+PrintGCDetails -XX:MetaspaceSize=64m
-XX:+HeapDumpOnOutofMemoryError -XX:HeapDumpPath=heap/heapdump.hprof
-XX:+PrintGCDateStamps -Xms50M -Xmx50M -Xloggc:log/gc-oomHeap.log
使用Java VisualVM分析dump文件
原因
1、代码中可能存在大对象分配
2、可能存在内存泄漏，导致在多次GC之后，还是无法找到一块足够大的内存容纳当前对象。
解决方法
1、检查是否存在大对象的分配，最有可能的是大数组分配
2、通过jmap命令，把堆内存dump下来，使用MAT等工具分析一下，检查是否存在内存泄漏的问题
3、如果没有找到明显的内存泄漏，使用-Xmx加大堆内存
4、还有一点容易被忽略，检查是否有大量的自定义的Finalizable对象，也有可能是框架内部提供的，考虑其存在的必要性
案例2：元空间溢出
JDK8后，元空间替换了永久代，元空间使用的是本地内存
原因：
1.运行期间生成了大量的代理类，导致方法区被撑爆，无法卸载
2.应用长时间运行，没有重启
3.元空间内存设置过小
解决方法：
因为该OOM原因比较简单，解决方法有如下几种：
1.检查是否永久代空间或者元空间设置的过小
2.检查代码中是否存在大量的反射操作
3.dump之后通过mat检查是否存在大量由于反射生成的代理类
性能优化1：调整堆大小提高服务的吞吐量
性能优化2：逃逸分析之栈上分配
堆，是分配对象的唯一选择吗？
在《深入理解]ava虚拟机中》关于Java堆内存有这样一段描述：
随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。
在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是如果经过逃逸分析（EscapeAnalysis）后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了，这也是最常见的堆外存储技术。
此外，前面提到的基于OpenJDK深度定制的TaoBaoVM，其中创新的GCIH（GCinvisible heap）技术实现off-heap，将生命周期较长的Java对象从heap中移至heap外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的。
逃逸分析
如何将堆上的对象分配到栈，需要使用逃逸分析手段。
逃逸分析（Escape Analysis）是目前Java虚拟机中比较前沿的优化技术。这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。
通过逃逸分析，Java虚拟机编译器能够分析出一个新的对象的引用的使用范围，从而决定是否要将这个对象分配到堆上。
逃逸分析的基本行为就是分析对象动态作用域：
当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。
栈上分配
使用逃逸分析，编译器可以对代码做如下优化：
栈上分配。将堆分配转化为栈分配。如果经过逃逸分析后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。可以减少垃圾回收时间和次数。
JIT编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须进行垃圾回收了。
同步消除
标量替换
标量（scalar）是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量，相对的，那些还可以分解的数据叫做聚合量（ABgregate）。
Java中的对象就是聚合量，因为他可以分解成其他聚合量和标量。
在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。
逃逸分析小结：逃逸分析并不成熟
其根本原因就是无法保证非逃逸分析的性能消耗一定能高于逃逸分析的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复茶的分析的，这其实也是一个相对耗时的过程。
一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。
虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。
性能优化3：合理配置堆内存
在案例1中我们讲到了增加内存可以提高系统的性能而且效果显著，那么随之带来的一个问题就是，我们增加多少内存比较合适？如果内存过大，那么如果产生FulIGC的时候，GC时间会相对比较长，如果内存较小，那么就会频繁的触发GC，在这种情况下，我们该如何合理的适配堆内存大小呢？
如何计算老年代存活对象？
JVM参数中添加GC日志，GC日志中会记录每次FulI GC之后各代的内存大小，观察老年代GC之后的空间大小。可观察一段时间内（比如2天）的FulI GC之后的内存情况，根据多次的Full GC之后老年代的空间大小数据来预估Full GC之后老年代的存活对象大小（可根据多次FuI GC之后的内存大小取平均值）。
性能优化4：CPU占用很高的排查方案
xxx大厂间题排查过程：
。。。省略；
4、ps auxlgrep java 查看到当前java进程使用cpu、内存、磁盘的情况获取使用量异常的进程
5、top -Hp 进程pid 检查当前使用异常线程的pid
6、把线程pid变为16进制，如31695 -> 7bcf然后得到0x7bcf
7、jstack 进程的pid lgrep -A20 0x7bcf 得到相关进程的代码
日均百万订单系统JVM参数设置
