巨大的 CopyOnWriteArrayList 导致的频繁 full GC 的症状
前2天看到有台机器的 Java 应用突然 CPU 高企, 再看其它metrics, 发现是由 GC 导致的, 但是看到 JVM available 内存, 却有很多, 再去观察 verboseGC log, 形状也很奇怪. 它到底是什么原因导致的呢?
前2天看到有台机器的 Java 应用突然 CPU 高企, 再看其它metrics, 发现是由 GC 导致的, 但是看到 JVM available 内存, 却有很多, 再去观察 verboseGC log, 形状也很奇怪. 它到底是什么原因导致的呢?
在公司有台台式机, 平时办公不用它, CPU 性能还可以, 有16G 内存, 为了充分利用它, 在它上面装了docker, 然后通过container的方式安装了不少工具, 比如: MySQL+phpmyadmin, ElasticSearch+kibana, MongoDB+mongoUI, Splunk, Clickhouse, Prometheus, Jupter Notebook, Neo4J, Janusgraph, Nginx 等应用, 平时做个测试或者小工具, 直接连这些应用, 非常方便. 直到有一天, 给它接了一个外接显示器, 第二天早上看到下面这个系统日志, 发现这个上面有个应用一直OOM.
今天遇到一起由于 ThreadLocal 没有正确使用引起的内存泄漏, 诊断过程中有些推断步骤还是有值得借鉴的意义的. 1: 如何快速找到当前线程中占用最大内存的对象; 2: 如何找到 ThreadLocal 变量的代码点.
最近分析了一个 Java 内存泄漏的例子, 干爆内存的不是业务对象, 竟然是 1162 万个 java.lang.ThreadGroup 对象. 到底是谁这么丧心病狂的创建这么多 ThreadGroup 又不释放呢? 为啥干爆 heap 的不是 ThreadGroup 里面的 Thread 呢?
今天查一个问题的时候, 去reivew 别人最近提交的代码, 发现有下面这个改动, 感觉很奇怪, 怎么去掉了为空的短路判断并且中间加了一个问号? 很是疑惑. 难道提交之前碰到键盘了?
再想想, 如果说这样, 本地测试应该就不会过吧, 于是开始怀疑自己. 果不其然, JavaScript 真的有这种操作符.