线上JVM thread 3000+ 未OOM的思考

大米饭66

已于 2022-08-24 21:24:41 修改

阅读量335

点赞数

分类专栏： java 文章标签： jvm java 开发语言

于 2022-08-24 20:56:57 首次发布

本文链接：https://blog.csdn.net/oschina_40730821/article/details/126511949

版权

java 专栏收录该内容

70 篇文章 1 订阅

订阅专栏

某天线上突然出了报警。

JVM Thread Count > 3000 触发。

首先观察集群的监控，发现不是个例，此应用的集群线程数都是2900~3000左右。

1.jstack 文件分析

经过业务和框架代码的问题，最终定位是存在大量 ZkClient 对象，每个 ZkClient 建连都会启动3个线程。

ZkClient 类会启动一个名称为 ZkClient-EventThread- 的线程。

接着调用 zkconnection.connect(watcher); 方法时，会创建一个 ClientCnxn 的实例。

org.apache.zookeeper.ClientCnxn#start 会启动，两个线程。localhost-startStop-sendThread 和 localhost-startStop-eventThread 。

问题原因最终定位，并修复。

同时给我产生了一定的困惑。

为什么3000+的线程却没有OOM？

理想中的计算公式

最大可用内存/Xss = 最大线程

Xss 参数配置 java8 及以上默认为 1024K

容器内存 5.5G,Xmx 堆内存 4G,元空间 256MB

可用内存 1280M/1M = 1280；最多1280左右个线程，机器就撑不住了。

网上查了一些资料

查看Thread 到底占用了多少内存

需要开启 JVM参数：-XX:NativeMemoryTracking=detail

然后执行 ,就可以看到 jvm 本地内存的分析

jcmd {pid} VM.native_memory

Native Memory Tracking:

Total: reserved=3439080KB, committed=2228892KB
-                 Java Heap (reserved=1468416KB, committed=1468416KB)
                            (mmap: reserved=1468416KB, committed=1468416KB)

-                     Class (reserved=1149482KB, committed=114346KB)
                            (classes #18958)
                            (malloc=2602KB #43119)
                            (mmap: reserved=1146880KB, committed=111744KB)

-                    Thread (reserved=238418KB, committed=238418KB)
                            (thread #856)
                            (stack: reserved=234588KB, committed=234588KB)
                            (malloc=2827KB #4282)
                            (arena=1003KB #1708)

-                      Code (reserved=266377KB, committed=94193KB)
                            (malloc=16777KB #19327)
                            (mmap: reserved=249600KB, committed=77416KB)

-                        GC (reserved=102043KB, committed=102043KB)
                            (malloc=14783KB #36820)
                            (mmap: reserved=87260KB, committed=87260KB)

-                  Compiler (reserved=1974KB, committed=1974KB)
                            (malloc=1844KB #3350)
                            (arena=131KB #6)

-                  Internal (reserved=179912KB, committed=179912KB)
                            (malloc=179880KB #86296)
                            (mmap: reserved=32KB, committed=32KB)

-                    Symbol (reserved=22345KB, committed=22345KB)
                            (malloc=19652KB #207060)
                            (arena=2693KB #1)

-    Native Memory Tracking (reserved=6934KB, committed=6934KB)
                            (malloc=536KB #7399)
                            (tracking overhead=6398KB)

-               Arena Chunk (reserved=309KB, committed=309KB)
                            (malloc=309KB)

-                   Unknown (reserved=2868KB, committed=0KB)
                            (mmap: reserved=2868KB, committed=0KB)

可以看到两种类型的内存：

“Reserved：” 由操作系统承诺的可用内存大小。但尚未分配，JVM 无法访问

”Committed：“ 已被 JVM 分配，可访问

在“Thread”部分可以看到，‘reserved’ 和 ‘committed’ 大小相同，接近于“线程数 ‘ 1MB”。这时因为 JVM 一开始就尽可能地为线程分配内存。

可以发现，确实实际占用内存没那么多。

查看每个线程栈的大小

JVM的线程在linux上底层是调用NPTL(Native Posix Thread Library)来创建的，一个JVM线程就对应linux的lwp(轻量级进程，也是进程，只不过共享了mm_struct，用来实现线程)，一个thread.start就相当于do_fork了一把。其中，我们在JVM启动时候设置了-Xss=512K(即线程栈大小)，这512K中然后有8K是必须使用的，这8K是由进程的内核栈和thread_info公用的，放在两块连续的物理页框上。如下图所示: