Tomcat出现假死原因及解决方法

1. 问题背景

线上环境因为有个接口内部在错误的参数下，会不断生成字符串，导致OOM，在OOM之后服务还能正常运行，但是发送的Api请求已经没有办法响应了。

2. 问题复现

模拟线上问题，在测试环境上进行复现，一段时间后服务会爆出OOM，但是不是每次都会导致Tomcat假死，有些情况下Tomcat还能正常访问。

情况一：核心线程丢失

OOM之前Tomcat线程情况

ID线程名称Group125http-nio-9989-Acceptor-0main126http-nio-9989-AsyncTimeoutmain123http-nio-9989-ClientPoller-0main124http-nio-9989-ClientPoller-1main113http-nio-9989-exec-1main

OOM之后Tomcat线程情况

ID线程名称Group123http-nio-9989-ClientPoller-0main1431http-nio-9989-exec-103main

情况二：服务重启

日志打印java.lang.OutOfMemoryError: Java heap space后，服务重启。

情况三：Tomcat后台线程丢失

只有后台线程丢失，但是Acceptor线程和Poller线程还存在

3. 假死情况

从Tomcat的NIO模型得知有几个组件，Acceptor、Poller、业务线程池。这三个组件情况如下：

Acceptor线程：该线程主要是监听连接（socket.accept()）,如果该线程挂掉，那么及时操作系统层面TCP3次握手成功，但是业务上也办法获取到这个连接。默认情况下，只有1个Acceptor线程，可以通过acceptorThreadCount参数设置。
Poller线程：Acceptor获取到连接之后，会轮询从Poller列表中取一个Poller进行处理。如果Poller线程挂掉了，那么就没法处理读请求了。默认情况下，会有min(2,cpu核数)个Poller线程，可以通过pollerThreadCount参数设置。
业务线程：Poller线程将读请求放到业务线程处理，如果业务线程阻塞（比如被某个网络IO阻塞），那么此刻的读请求还在业务线程池的队列中，没有被处理。默认情况下，最小线程为10，可以通过minSpareThreads参数设置，最大线程为200，可以通过maxThreads参数设置。

此时分析再结合复现的情况，如果核心线程挂掉，那确实存在假死情况。但是从事发现场来看，并没有发现Tomcat的Acceptor、Poller线程打印出OutofMemoryError的异常，及时将org.apache.tomcat和org.apache.catalina设置成Debug级别。因此需要深入源码分析。

4. 异常处理分析

4.1 Acceptor异常处理分析

Acceptor逻辑如下，就是在循环内不断地监听accept()，查看是否有新连接。

//NioEndpoint$Acceptor#run
protected class Acceptor extends AbstractEndpoint.Acceptor {
@Override
public void run() {
int errorDelay = 0;
// Loop until we receive a shutdown command
while (running) {
//…忽略一些代码
state = AcceptorState.RUNNING;
try {
//if we have reached max connections, wait
countUpOrAwaitConnection();
SocketChannel socket = null;
try {
socket = serverSock.accept();
} catch (IOException ioe) {
}
// Successful accept, reset the error delay
errorDelay = 0;
// Configure the socket
if (running && !paused) {
// setSocketOptions() will hand the socket off to
// an appropriate processor if successful
if (!setSocketOptions(socket)) {
closeSocket(socket);
}
} else {
closeSocket(socket);
}
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
log.error(sm.getString(\”endpoint.accept.fail\”), t);
}
}
state = AcceptorState.ENDED;
}
//…忽略一些代码
}

其中setSocketOptions是往Poller中调用register方法，把这个Socket传递过去。getPoller0()方法会以轮询的策略获取一个Poller

//NioEndpoint#setSocketOptions
protected boolean setSocketOptions(SocketChannel socket) {
// Process the connection
try {
//disable blocking, APR style, we are gonna be polling it
socket.configureBlocking(false);
Socket sock = socket.socket();
socketProperties.setProperties(sock);

NioChannel channel = nioChannels.pop();
if (channel == null) {
SocketBufferHandler bufhandler = new SocketBufferHandler(
socketProperties.getAppReadBufSize(),
socketProperties.getAppWriteBufSize(),
socketProperties.getDirectBuffer());
if (isSSLEnabled()) {
channel = new SecureNioChannel(socket, bufhandler, selectorPool, this);
} else {
channel = new NioChannel(socket, bufhandler);
}
} else {
channel.setIOChannel(socket);
channel.reset();
}
getPoller0().register(channel);
} catch (Throwable t) {
ExceptionUtils.handleThrowable(t);
try {
log.error(\”\”,t);
} catch (Throwable tt) {
ExceptionUtils.handleThrowable(tt);
}
// Tell to close the socket
return false;
}
return true;
}

此处重点看一下ExceptionUtils.handleThrowable方法的逻辑，因为OutofMemoryError是VirtualMachineError的子类，所以这里会被直接抛出异常，。而OutofMemeoryError属于 uncheck exception，抛出uncheck exception就会导致线程终止，并且主线程和其他线程无法感知这个线程抛出的异常。如果线程代码（run方法之外）之外来捕获这个异常的话，可以通过Thread的setUncaughtExceptionHandler处理。

//ExceptionUtils#handleThrowable
public static void handleThrowable(Throwable t) {
if (t instanceof ThreadDeath) {
throw (ThreadDeath) t;
}
if (t instanceof StackOverflowError) {
// Swallow silently – it should be recoverable
return;
}
if (t instanceof VirtualMachineError) {
throw (VirtualMachineError) t;
}
// All other instances of Throwable will be silently swallowed
}

再看启动的时候，线程是否会设置uncaughtExceptionHandler，发现并没有设置，所以异常没法被正常打印到日志中。

//AbstractEndpoint#startAcceptorThreads
protected final void startAcceptorThreads() {
int count = getAcceptorThreadCount();
acceptors = new Acceptor[count];

for (int i = 0; i < count; i++) {
acceptors[i] = createAcceptor();
String threadName = getName() + \”-Acceptor-\” + i;
acceptors[i].setThreadName(threadName);
Thread t = new Thread(acceptors[i], threadName);
t.setPriority(getAcceptorThreadPriority());
t.setDaemon(getDaemon());
t.start();
}
}

小结：OutofMemoryError被捕获了，然后重新抛出，但是因为OutofMemoryError是uncheck exception，而线程没有设置uncaughtExceptionHandler，所以没法被打印。

4.2 增加全局异常捕获

在启动的时候，设置全局线程nncaughtException处理器。这里简单打印线程名称，并且抛出异常。

Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
@Override
public void uncaughtException(Thread t, Throwable e) {
logger.error(\”[Global Handler]thread-name:{},happen exp,\”, t.getName(), e);
}
});

重新复现问题，发现Acceptor线程有打印异常情况。

不过，同时也发现，Poller线程有打印错误日志，但并不是全局处理器打印的。

下图为Arthas截图，发现仍然Poller线程仍然存在。因此再分析Poller的异常处理。

4.3 Poller异常处理

从上面的异常日志俩看，Poller线程是在处理PollerEvent中处理REGISTER事件时的抛出异常，查看相关代码。发现此处捕获的是Exception，而OutofMemoryError属于Error，所以此处不会被捕获到，并且会往上抛出。

//NioEndpoint$Poller#events
public void run() {
if (interestOps == OP_REGISTER) {
try {
socket.getIOChannel().register(
socket.getPoller().getSelector(), SelectionKey.OP_READ, socketWrapper);
} catch (Exception x) {
log.error(sm.getString(\”endpoint.nio.registerFail\”), x);
}
}
//…
}

在Poller的events方法中，会循环调用PollerEvent的run方法，这里内部有捕获一个Throwable，而Error是继承Throwable。所以OutofMemoryError会在这里被捕获，而且会打印日志，并且线程不会挂掉。

//NioEndpoint$Poller#events
public boolean events() {
boolean result = false;

PollerEvent pe = null;
for (int i = 0, size = events.size(); i < size && (pe = events.poll()) != null; i++ ) {
result = true;
try {
pe.run();
pe.reset();
if (running && !paused) {
eventCache.push(pe);
}
} catch ( Throwable x ) {
log.error(\”\”,x);
}
}

return result;
}

而在Poller的循环中，发现也有ExceptionUtils.handleThrowable处理，如果在这里出现OutofMemoryError异常的话，那么Poller线程将会被终止。

//NioEndpoint$Poller#run
public class Poller implements Runnable {
public void run() {
// Loop until destroy() is called
while (true) {
Boolean hasEvents = false;
try {
if (!close) {
hasEvents = events();
//….
}
}catch (Throwable x) {
ExceptionUtils.handleThrowable(x);
log.error(\”\”,x);
continue;
}
//…
}
}
}