bruce128的专栏

容器内存告警显示使用3.5GB，但实际JVM进程仅占用1.2GB物理内存。排查发现k8s监控读取的是cgroup的memory.usage_in_bytes值（RSS+Cache+Swap）。而Cache（pagecache）会被系统自动回收，并非真实内存占用。建议运维改用RSS指标监控，避免误报。主要依据cgroup文档说明和实际memory.stat文件数据验证，RSS+Cache之和等于监控值。

生产上遇到了一些容器实例被OOM的现象，总结一下OOM的两种触发条件。我的虚拟机是ubuntu 24.0.4版本，分配4G内存，在我的虚拟机上复现这两种case。

docker耗用完内存前，堆内存并没有达到上限，于是没有触发老年代GC，内存没有降下去。如果容器OOM killed，容器里的jvm进程没有Full GC，那么肯定是MaxRAMPercentage参数太高，导致堆内存没有用到上限，无法触发堆内存（老年代）GC。当实例内存超过95%时，对比top显示的的jvm进程内存和ps stats输出的docker实例内存信息，其余进程耗用的内存忽略不计。遂将内存增加到4GB。4 由于堆内存没有的到达上限，但是整个jvm进程内存超出了容器的内存限制。

我开发的worker，每隔几个月线上都会阻塞一次，一直都没查出问题。今天终于了了这个心结。把解决过程总结下和大家分享。 首先用jstack命令打出这个进程的全部线程堆栈。拿到线程dump文件之后，搜索自己的worker名字。"DefaultQuartzScheduler_Worker-10" prio=10 tid=0x00007f55cd54d800 nid=0x3e2e wait

今天线上一个tomcat进程cpu负载100%。按以下步骤查出原因。    1.执行top -c命令，找到cpu最高的进程的id    2.执行top -H -p pid，这个命令就能显示刚刚找到的进程的所有线程的资源消耗情况。找到CPU负载高的线程tid 8627, 把这个数字转换成16进制，21B3。    3.执行jstack -l pid，拿到进程的线程dump文件。这个命令会

一、JDK1.8 JVM内存模型概览这里介绍的是JDK1.8 JVM内存模型。1.8同1.7比，最大的差别就是：元数据区取代了永久代。元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元数据空间并不在虚拟机中，而是使用本地内存。二、各区域介绍1. 程序计数器每个线程一块，指向当前线程正在执行的字节码代码的行号。如果当前线程执...

一 问题背景  通过POI框架生成excel文件的时候，一般选用的是XSSFWorkbook类。用这个类生成excel文件时，文件的所有数据均会存放在内存当中，包括cell对象，cellType对象等等。如果数据少的话，内存还能撑得住，但是超过了万行级别，内存就会被打爆。POI框架开发者直到3.8版本才提供了SXSSFWorkbook类用以解决这个问题。 Since 3.8-beta3...

一 问题背景  一直在跟进excel的商品批量发布功能。去年大促前的半个月时间里用户频繁上传excel文件，导致线上机器频繁fullGC。虽然没有OOM，但是一直对吃内存问题耿耿于怀。通过堆dump分析，发现主要是poi框架的类实例耗用内存太大。poi框架的开发者也意识到了这个问题，通过提供比较底层的事件模式，解决吃内存的问题。 The SS eventmodel package is...

    刚上线了一个新的应用集群，第二天和第三天收到了应用FullGc超过阈值的报警短信。但是观察报警Java实例的jvm监控，堆内存仅仅用了1G多一点，还富余近700M。很困惑，剩余这么多内存没被使用，那么说明老年代内存是充足的才对啊!    同事提醒我是不是申请了什么大对象，诚然，老年代只会有两种类型的对象:     1. 多次Minor Gc中存活的小对象    2. 大对象，即超过了Pre...