tomcat线程阻塞主因是连接器参数失配或jvm内存/gc问题，而非环境变量配置；典型表现包括acceptor线程异常退出、maxthreads与acceptcount不匹配导致请求堆积或拒绝、堆内存设置过大触发频繁gc或oom。
Tomcat线程阻塞和环境变量配置基本无关，强行改JAVA_OPTS或CLASSPATH反而容易触发阻塞。真正导致线程卡在RUNNABLE或WAITING状态的，是JVM内存不足、连接器参数失配、或Acceptor/AsyncTimeout等关键线程异常终止——环境变量只是“背锅侠”。
为什么改JAVA_OPTS后线程开始阻塞？
常见现象是：加了-Xms4g -Xmx4g或-XX:MaxMetaspaceSize=512m后，应用启动变慢、请求响应延迟飙升、jstack里大量线程停在java.lang.Thread.sleep或sun.nio.ch.EPollArrayWrapper.epollWait。这不是环境变量本身的问题，而是它暴露了底层矛盾：
- 堆内存设得过大（如
-Xmx8g），但物理内存或容器限制只有4G，触发频繁GC甚至OutOfMemoryError: Java heap space，导致http-nio-8080-Acceptor-0线程OOM退出，后续请求无法接入 - 误加
-XX:+UseParallelGC在高并发IO场景，GC线程抢占CPU，使NIO Poller线程得不到调度，表现为“线程活着但不干活” - 把
CLASSPATH指向了旧版tomcat-native.dll或冲突的apr-1.dll，导致Http11AprProtocol初始化失败，回退逻辑卡死在类加载阶段
server.xml里maxThreads和acceptCount配错才是真凶
线程阻塞最常发生在连接器（Connector）层面，而非JVM启动参数。重点盯住这两个值：
-
maxThreads设得太小（如默认200），而瞬时并发超300，新请求会排队进acceptCount队列；一旦队列满（默认100），后续连接直接被操作系统reject，客户端看到超时，但Tomcat线程数却“看起来正常”——实际是请求根本没进来 -
acceptCount设得过大（如1000），但maxThreads没同步放大，会导致大量请求堆积在队列里等待，jstack中出现大量WAITING on java.util.concurrent.ThreadPoolExecutor$Worker，线程池饥饿 - NIO模式下，
maxConnections（默认10000）若远高于maxThreads，连接能建起来，但请求处理不过来，表现为“端口通、页面打不开”，netstat -an | grep :8080 | wc -l显示大量ESTABLISHED但无响应
如何快速验证是不是Acceptor线程挂了？
Acceptor线程一崩，Tomcat就“假活”：进程在、端口监听着、日志没报错，但新请求完全进不来。用三步定位：
- 执行
ps -T -p $PID | grep http-nio | grep Acceptor，看是否输出为空；若空，说明http-nio-8080-Acceptor-0已终止 - 查
catalina.out，搜Exception in thread "http-nio-，大概率跟着OutOfMemoryError或NoClassDefFoundError - 用
jstack $PID | grep -A 10 "http-nio.*Acceptor"确认线程栈是否存在；若无输出，且http-nio.*ClientPoller也消失，基本可断定Acceptor崩溃
真正要调的不是环境变量，而是server.xml里Connector的maxThreads、minSpareThreads、acceptCount，以及JVM参数中与GC策略、堆外内存相关的部分。盲目加大JAVA_OPTS内存，等于给一个漏气的轮胎猛打气——压强上去了，爆得更快。
