OOM
OOM-内存
OOM: out of memory
关于JVM的内存相关的配置很多开源的JAVA组件上有对应的推荐
eg:http://rocketmq.apache.org/docs/system-config/
1. 内存分配 线上jvm-没有太多样
> jvm堆内存占70%机器总内存(经验值)
> 相同的Xms和Xmx值---提升系统稳定性 不用再不够的情况下让os给jvm分配内存
> -XX+AlwayPreTouch 启动后分配到位 ---linux预分配而不是实际分配,实际用的时候
2.内存使用
GC–>JVM中大部分的工作集中地–>STW stop the word
优化方向:
如何减少STW时间
- 面试问题:JVM做了什么GC方面的调整 ----并行改并发垃圾收集器
- 低延迟应用下,需要调整垃圾收集器的参数-- 一般在内部系统中的调用,不然网络延迟影响比较大,调优不明显
- 根据实际的测试情况,在代码层面无法优化的情况下,最后的保留手段
如何减少GC的次数
- 轻jvm参数配置
- 重代码编写
- 逃逸分析:分析能不能被其他线程访问
- 线上分配机制:1.对象大部分分配到Eden区 2.大对象直接进入老年代
[XX:+PretenureSizeThreshold]
- 栈上分配:对象不分配到堆里
- 标量替换:
面试:集中点在 分代回收的机制-分代回收
分配到堆里遵循-TLAB( thread local allocation buffer)防止多个线程使用同一个内存位置放对象故比在栈上慢些
3.实操–OOM问题
1.最常见 java.lang.OutOfMemorryError: java heap spave
-内存泄露: 你不知道的情况下,内存资源没有释放或者及大量占用
2. java.lang.OutOfMemorryError: GC overhead limit exceeded
- 当GC花费了程序运行总时间的98%以上 而回收不到2%的堆内存,则抛出异常
- -XX:-UserGCOverHeadLimit 可以关闭这个功能(不建议,关闭后内存不够还是会抛出异常java heap spave)
3.java.lang.OutOfMemoryError: Metaspace
-迷惑行为之--OOM异常被捕获后,重新包装
-调整为更大的方法区【永久代/元数据空间】
-场景: weblogic、tomcate不重启发布新版本、重新装包
3. java.lang.OutOfMemorryError:: unable to create new native thread
-操作系统层面 线程数量限制,内存不够。。。。
-不同的操作系统不同的表现
4. java.lang.OutOfMemorryError: Requested arry size exceeds VM limit
数组范围大小限制
6 java.lang.OutOfMemorryError: Direct buffer memory .-XX:MaxDirectMemorySize
7.操作系统lnux --ooM killer机制(保护机制) man malloc
linux预分配而不是实际分配,实际用的时候再分配
不够用的时候,出发killer--找一个进程干掉它【linux做一个排名,来进行干掉】
生产环境可能碰到 ,无缘无故jvm挂了--操作系统会有日志 关键字kill
/var/log/messages
5. out of swap space
物理内存和交换空间不足
4. OOM–线上问题解决方案
- 配置参数保存对应的dump文件
- -Xmx8m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/temp/202006.hprof
- 用工具jhat或其他的工具(eg:MAT memory analisys tool)打开对用的文件 ,发现一个arraylist对象占用了内存的80%+
然后右击找到对应的GC root
- 可看到GCroot是一个线程对象,
- 右击查看线程detail就可以找到对应的类。
示例代码:
package com.tony.edu.jvm.MemoryLeak;
import java.util.ArrayList;
import java.util.concurrent.CountDownLatch;
// -Xmx8m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/temp/202006.hprof
public class OOM_Memory_leak_Service {
// 系统用户一万以内,表数据【日志文件】100万,SQL去重占用数据库资源,导致其他SQL执行缓慢
// 采取JAVA分页查询100次 ,信息去重
public ArrayList distinct() throws InterruptedException {
ArrayList userList = new ArrayList(); // 预计 1W条数据
CountDownLatch countDownLatch = new CountDownLatch(1);
new Thread(() -> {// 创建了新的线程去执行具体的代码逻辑
try {
for (int j = 0; j < 100; j++) {
for (int i = 0; i < 10000; i++) {
// 每次循环,创建一个新的User对象,但是ID 范围在 1W以内
User user = new User(String.valueOf(i)); // TODO 模拟从数据库中查询出一个对象
// 如果cache中没有,则存入cache集合
if (!userList.contains(user)) { // 理论上:存储不超过1W条 用户对象
userList.add(user);
}
}
}
} catch (Exception e) {
e.printStackTrace();
} finally {
countDownLatch.countDown();
}
}).start();
countDownLatch.await(); // 等待 计数器 归 0
return userList;
}
public static void main(String[] args) throws InterruptedException {
new OOM_Memory_leak_Service().distinct();
}
}
2.通过内存快照定位可疑代码段
3.不要去怀疑这里内存泄露,分析 内存分配是否合理 结合业务场景
4.然后再去分析代码逻辑错误,是否存在bug. (此处原因位contains里是equals方法)
5.警惕Full GC
- 1.生产环境中监控要完善···内存使用清苦那个、GC等
package com.tony.edu.jvm.gc;
import jxl.Cell;
import jxl.Sheet;
import jxl.Workbook;
import jxl.WorkbookSettings;
import java.io.File;
// 使用server模式运行 开启GC日志
// -Xmx512m -server -verbose:gc -XX:+PrintGCDetails
// 很多人都会建议的规避System.gc带来的fullgc风险
// -XX:+DisableExplicitGC 禁止程序显示调用gc方法(尽量不要这么做,上线前测试好就行了)
public class FullGCDemo {
public static void main(String[] args) throws Exception {
for (int i = 0; i < 1000; i++) {
WorkbookSettings workbookSettings = new WorkbookSettings();
workbookSettings.setGCDisabled(true);
Workbook book = Workbook.getWorkbook(new File(FullGCDemo.class.getClassLoader().getResource("FullGCDemo2.xls").getFile()), workbookSettings);
// 获得第一个工作表对象
Sheet sheet = book.getSheet(0);
// 得到第一列第一行的单元格
Cell cell1 = sheet.getCell(0, 0);
String result = cell1.getContents();
System.out.println(result);
book.close(); // 第三方依赖包,内部可能使用了system.gc()
Thread.sleep(2000L);
}
}
}
// TODO linux环境下测试
// 编译:javac -cp /u01/jvm-study/ExcelFullGCDemo/jxl-2.6.12.jar:/u01/jvm-study/ExcelFullGCDemo FullGCDemo.java
// 运行: java -Xmx512m -server -verbose:gc -XX:+PrintGCDetails -cp /u01/jvm-study/ExcelFullGCDemo/jxl-2.6.12.jar:/u01/jvm-study/ExcelFullGCDemo FullGCDemo
-
- System.gc跟踪
-
- brace工具-》-openjdk提供的动态跟踪工具-》理解为动态AOP
-作业:通过brace跟踪定位到ByteBuffer.allocateDirect堆外内存调用之处。
- brace工具-》-openjdk提供的动态跟踪工具-》理解为动态AOP
// 这是一个脚本,通过btrace工具运行
@BTrace
public class TracingSystemGCScript {
/* put your code here */
@OnMethod(
clazz = "java.lang.System",
method = "gc"
)
public static void traceExecute() {
println("who call System.gc :");
jstack();
}
}