JDK8版本的内存结构如下
JDK8版本的内存结构
GC 主要工作在 Heap 区和 MetaSpace 区（上图蓝色部分），在 Direct Memory 中，如果使用的是 DirectByteBuffer，那么在分配内存不够时则是 GC 通过 Cleaner#clean 间接管理。
任何自动内存管理系统都会面临的步骤：为新对象分配空间，然后收集垃圾对象空间，下面我们就展开介绍一下这些基础知识。
Java 中对象地址操作主要使用 Unsafe 调用了 C 的 allocate 和 free 两个方法，分配方法有两种：
目前在 Hotspot VM 中主要有分代收集和分区收集两大类
分代收集和分区收集
参数配置：
//设置Serial垃圾收集器（新生代）
开启：-XX:+UseSerialGC
//设置PS+PO,新生代使用功能Parallel Scavenge 老年代将会使用Parallel Old收集器
开启 -XX:+UseParallelOldGC
//CMS垃圾收集器（老年代）
开启 -XX:+UseConcMarkSweepGC
//设置G1垃圾收集器
开启 -XX:+UseG1GC现象：垃圾收集频率非常频繁。
原因：如果内存太小，就会导致频繁的需要进行垃圾收集才能释放出足够的空间来创建新的对象，所以增加堆内存大小的效果是非常显而易见的。
注意：如果垃圾收集次数非常频繁，但是每次能回收的对象非常少，那么这个时候并非内存太小，而可能是内存泄露导致对象无法回收，从而造成频繁GC。
参数配置：
//设置堆初始值
指令1：-Xms2g
指令2：-XX:InitialHeapSize=2048m
//设置堆区最大值
指令1：`-Xmx2g`
指令2： -XX:MaxHeapSize=2048m
//新生代内存配置
指令1：-Xmn512m
指令2：-XX:MaxNewSize=512m现象：某一个区域的GC频繁，其他都正常。
原因：如果对应区域空间不足，导致需要频繁GC来释放空间，在JVM堆内存无法增加的情况下，可以调整对应区域的大小比率。
注意：也许并非空间不足，而是因为内存泄造成内存无法回收。从而导致GC频繁。
参数配置：
//survivor区和Eden区大小比率
指令：-XX:SurvivorRatio=6 //S区和Eden区占新生代比率为1:6,两个S区2:6
//新生代和老年代的占比
-XX:NewRatio=4 //表示新生代:老年代 = 1:4 即老年代占整个堆的4/5；默认值=2现象：老年代频繁GC，每次回收的对象很多。
原因：如果升代年龄小，新生代的对象很快就进入老年代了，导致老年代对象变多，而这些对象其实在随后的很短时间内就可以回收，这时候可以调整对象的升级代年龄，让对象不那么容易进入老年代解决老年代空间不足频繁GC问题。
注意：增加了年龄之后，这些对象在新生代的时间会变长可能导致新生代的GC频率增加，并且频繁复制这些对象新生的GC时间也可能变长。
配置参数：
//进入老年代最小的GC年龄,年轻代对象转换为老年代对象最小年龄值，默认值7
-XX:InitialTenuringThreshol=7 现象：老年代频繁GC，每次回收的对象很多,而且单个对象的体积都比较大。
原因：如果大量的大对象直接分配到老年代，导致老年代容易被填满而造成频繁GC，可设置对象直接进入老年代的标准。
注意：这些大对象进入新生代后可能会使新生代的GC频率和时间增加。
配置参数：
//新生代可容纳的最大对象,大于则直接会分配到老年代，0代表没有限制。
-XX:PretenureSizeThreshold=1000000 现象：CMS，G1 经常 Full GC，程序卡顿严重。
原因：G1和CMS 部分GC阶段是并发进行的，业务线程和垃圾收集线程一起工作，也就说明垃圾收集的过程中业务线程会生成新的对象，所以在GC的时候需要预留一部分内存空间来容纳新产生的对象，如果这个时候内存空间不足以容纳新产生的对象，那么JVM就会停止并发收集暂停所有业务线程（STW）来保证垃圾收集的正常运行。这个时候可以调整GC触发的时机（比如在老年代占用60%就触发GC），这样就可以预留足够的空间来让业务线程创建的对象有足够的空间分配。
注意：提早触发GC会增加老年代GC的频率。
配置参数：
//使用多少比例的老年代后开始CMS收集，默认是68%，如果频繁发生SerialOld卡顿，应该调小
-XX:CMSInitiatingOccupancyFraction
//G1混合垃圾回收周期中要包括的旧区域设置占用率阈值。默认占用率为 65%
-XX:G1MixedGCLiveThresholdPercent=65 代码
public class DeadLockTest {
private static Object lock1 = new Object();
private static Object lock2 = new Object();
public static void main(String[] args) {
new Thread(() -> {
synchronized (lock1) {
try {
System.out.println("thread1 begin");
Thread.sleep(5000);
} catch (InterruptedException e) {
}
synchronized (lock2) {
System.out.println("thread1 end");
}
}
}).start();
new Thread(() -> {
synchronized (lock2) {
try {
System.out.println("thread2 begin");
Thread.sleep(5000);
} catch (InterruptedException e) {
}
synchronized (lock1) {
System.out.println("thread2 end");
}
}
}).start();
System.out.println("main thread end");
}
}启动：
java DeadLockTest使用jps查询当前的java进程，得到对应的程序进程pid
排查死锁,使用jstack的命令，得到的线程栈信息
jstack pid
线程栈信息
从图中就很明显看到一个死锁的提示
代码
public class FullGC {
private static ScheduledThreadPoolExecutor executor =
new ScheduledThreadPoolExecutor(10, new ThreadPoolExecutor.DiscardOldestPolicy());
public static void main(String[] args) throws Exception {
executor.setMaximumPoolSize(50);
while(true) {
test();
Thread.sleep(100L);
}
}
private static void test() {
List userList = getUserListInfo();
userList.forEach((info) -> {
executor.scheduleWithFixedDelay(() -> {
info.emptyMethod();
}, 2L, 3L, TimeUnit.SECONDS);
});
}
private static List getUserListInfo() {
List userList = new ArrayList();
for(int i = 0; i < 100; ++i) {
User user = new User();
userList.add(user);
}
return userList;
}
private static class User {
String name;
int age;
Date birthdate;
private User() {
this.name = String.valueOf(new Random().nextInt(10));
this.age = new Random().nextInt(10);
this.birthdate = new Date();
}
public void emptyMethod() {
}
}
} 启动命令：
java -Xmx20m -Xms20m -XX:+PrintGC com.andy.jvm.gc.FullGC排查
问题分析：CPU高一定是某个程序长期占用了CPU资源。
top 列出系统各个进程的资源占用情况top -Hp 进程ID 列出对应进程里面的线程占用资源情况printf "%x
" PID 把线程ID转换为16进制。
jsack PID 打印出进程的所有线程信息，从打印出来的线程信息中找到上一步转换为16进制的线程ID对应的线程信息。jstat -gc PID 1000 查看GC次数，时间等信息，每隔一秒打印一次。
jmap -histo PID | head -20 查看堆内存占用空间最大的前20个对象类型,可初步查看是哪个对象占用了内存。jmap - histo 4655 | head -20
jmap -dump:format=b,file=xxx pid
jmap -dump:live,format=b,file=/home/myheapdump.hprof PID dump堆内存信息到文件。使用jvisualVM对dump文件进行离线分析,找到占用内存高的对象，再找到创建该对象的业务代码位置，从代码和业务场景中定位具体问题。
现象：
服务刚刚启动时 GC 次数较多，最大空间剩余很多但是依然发生 GC，这种情况我们可以通过观察 GC 日志或者通过监控工具来观察堆的空间变化情况即可。GC Cause 一般为 Allocation Failure，且在 GC 日志中会观察到经历一次 GC ，堆内各个空间的大小会被调整，如下图所示：
动态扩容引起的空间震荡
解决：
在 JVM 的参数中 -Xms 和 -Xmx 设置的不一致，在初始化时只会初始 -Xms 大小的空间存储信息，每当空间不够用时再向操作系统申请，这样的话必然要进行一次 GC。
另外，如果空间剩余很多时也会进行缩容操作，JVM 通过 -XX:MinHeapFreeRatio 和 -XX:MaxHeapFreeRatio 来控制扩容和缩容的比例，调节这两个值也可以控制伸缩的时机。
尽量将成对出现的空间大小配置参数设置成固定的，如 -Xms 和 -Xmx，-XX:MaxNewSize 和 -XX:NewSize，-XX:MetaSpaceSize 和 -XX:MaxMetaSpaceSize 等
这个问题虽然初级，但是发生的概率还真不小，尤其是在一些规范不太健全的情况下。
页面更新：2024-04-11
本站资料均由网友自行发布提供，仅用于学习交流。如有版权问题，请与我联系，QQ：4156828
© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号
