JVM 參數對 Tomcat 線程容量的影響實測：-Xmx 越大反而能開的線程越少？

生產環境 Tomcat 繁忙期拋 java.lang.OutOfMemoryError: unable to create new native thread。本文通過受控實驗 (2GB 記憶體、4 核 CPU、Tomcat 4.1.30、JMeter 壓測、JConsole 監控) 揭示 -Xmx、-Xms、-Xss 對線程上限的真實影響，並給出 Linux 核心參數調優方案。

實驗設計

• 簡單 JSP：Thread.sleep(30000) 保持請求佔用線程。
• JMeter 遞增併發直到 Tomcat 崩潰/拒絕連線。
• 記錄崩潰時 Tomcat 線程數 (java.lang.ThreadingMXBean)。

實測數據表

核心發現

1. -Xmx 越大，可建立線程數越少：堆內存佔用物理記憶體，擠壓作業系統可用於線程棧 (native memory) 的空間。
2. -Xss (線程棧大小) 在此實驗中幾乎不影響極限：因為瓶頸在於 **OS 進程虛擬記憶體限制 (ulimit -v / /proc/sys/vm/max_map_count)**，而非單線程棧大小。
3. Tomcat 線程為 **Linux 原生線程 (pthread)**，棧內存從 **進程虛擬記憶體空間** 分配，不受 JVM 堆控制。

記憶體佈局模型 (32 位 JVM 關鍵)

4GB 進程虛擬地址空間
├── Kernel Space (1-2GB)
└── User Space (2-3GB)
    ├── JVM Heap (-Xmx)
    ├── PermGen / Metaspace
    ├── Code Cache
    ├── Direct ByteBuffer (-XX:MaxDirectMemorySize)
    ├── Thread Stacks (-Xss * threadCount)  ← 瓶頸在這裡
    ├── JNI / Native Libraries
    └── mmap 映射文件

解決方案：調整 Linux 核心參數

1. 增加進程最大映射區域數

# /etc/sysctl.conf
vm.max_map_count = 262144  # 預設 65530，每線程約需 1-2 個 VMA
sysctl -p

2. 調大用戶進程虛擬記憶體限制

# /etc/security/limits.conf
tomcat soft as unlimited
tomcat hard as unlimited
# 或啟動腳本 ulimit -v unlimited

3. 遷移至 64 位 JVM (根治)

• 64 位進程虛擬地址空間 128TB+，徹底消除地址空間壓力。
• 現代生產環境**強制要求 64 位 JDK** (JDK 8+ 默認 64 位)。

4. 線程池上限保護

防止無限制創建線程耗盡 OS 資源。

現代監控指標 (JDK 11+ / Prometheus)

• jvm_threads_live、jvm_threads_daemon、jvm_threads_peak。
• jvm_memory_bytes_used{area="nonheap"} 監控非堆 (含線程棧)。
• 告警閾值：jvm_threads_live > maxThreads * 0.8 觸發擴容/限流。