【问题标题】:Avoiding thread starvation caused by slow clients in tomcat/spring-boot避免tomcat/spring-boot中慢客户端导致的线程饥饿
【发布时间】:2015-03-14 15:27:38
【问题描述】:

我有一个简单的 spring-boot 应用程序。它有一个端点,从请求正文中获取一个对象,并且什么都不做:

@Controller
class FooController {
    @RequestMapping(method=RequestMethod.POST, value="/foo")
    public void postFoo(@RequestBody Foo foo) {
    }
}

很简单的东西。

然后我通过 telnet 连接并通过适当的标头发送,就好像我要发送一个 json 编码的对象一样,但从不发送请求正文 - 我只是让连接挂起。

运行jstack,可以看到tomcat已经将请求分派给spring了。 Spring 已将其发送给 jackson。 Jackson 在 NIO 上被阻止,等待更多数据进入。

Thread 12128: (state = BLOCKED)
 - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame; information may be imprecise)
 - java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long) @bci=20, line=226 (Compiled frame)
 ...
 - org.apache.tomcat.util.net.NioEndpoint$KeyAttachment.awaitLatch(java.util.concurrent.CountDownLatch, long, java.util.concurrent.TimeUnit) @bci=18, line=1582 (Compiled frame)
 ...
 - org.apache.tomcat.util.net.NioSelectorPool.read(java.nio.ByteBuffer, org.apache.tomcat.util.net.NioChannel, java.nio.channels.Selector, long) @bci=7, line=227 (Compiled frame)
 - org.apache.coyote.http11.InternalNioInputBuffer.readSocket(boolean, boolean) @bci=103, line=427 (Compiled frame)
...
 - org.apache.catalina.connector.CoyoteInputStream.read(byte[], int, int) @bci=76, line=200 (Compiled frame)
 - com.fasterxml.jackson.core.json.ByteSourceJsonBootstrapper.ensureLoaded(int) @bci=49, line=503 (Compiled frame)
 ...
 - com.fasterxml.jackson.databind.ObjectMapper.readValue(java.io.InputStream, com.fasterxml.jackson.databind.JavaType) @bci=6, line=2158 (Compiled frame)
 - org.springframework.http.converter.json.MappingJackson2HttpMessageConverter.readJavaType(com.fasterxml.jackson.databind.JavaType, org.springframework.http.HttpInputMessage) @bci=11, line=225 (Compiled frame)
 ...
 - org.springframework.web.servlet.FrameworkServlet.doPost(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=3, line=863 (Compiled frame)
 - javax.servlet.http.HttpServlet.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=149, line=646 (Compiled frame)
 - org.springframework.web.servlet.FrameworkServlet.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) @bci=32, line=837 (Compiled frame)
 - javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) @bci=30, line=727 (Compiled frame)
 - org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse) @bci=446, line=303 (Compiled frame)
 ...
 - org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(java.nio.channels.SelectionKey, org.apache.tomcat.util.net.NioEndpoint$KeyAttachment) @bci=140, line=1736 (Interpreted frame)
 - org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run() @bci=94, line=1695 (Compiled frame)
 - java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=95, line=1145 (Compiled frame)
 - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=615 (Interpreted frame)
 - org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run() @bci=4, line=61 (Interpreted frame)
 - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)

我的问题是,如果有 200 人这样做,那么我的线程池就会被饿死,合法请求就无法进入。这似乎是针对运行在 tomcat 上的任何东西的非常简单的 DOS 攻击。

我认为有一种方法可以解决此问题,即让 NIO HTTP 连接器提前读取其缓冲区。如果是这样,我将如何进行设置?

即便如此,恶意代理似乎也可以通过向服务发送大型对象来轻松关闭服务。当连接缓慢、有问题或恶意的客户端时,人们通常如何防止线程饥饿?

【问题讨论】:

  • 马丁,我需要你发布更多的堆栈。我有一种感觉,该线程被锁定在该 CountdownLatch 上两次。来自非阻塞套接字的所有读/写操作都是......非阻塞的。这意味着 read() 将返回当前可用的数据,不再等待。
  • @Martin:你得到解决方案了吗?如果有人能解决,请提供解决方案。

标签: java tomcat nio


【解决方案1】:

查看 Tomcat 中的 Stuck Thread Detection Valve

来自文档:

此阀门允许检测需要很长时间才能处理的请求, 这可能表明正在处理它的线程被卡住了。 此外,它可以选择中断此类线程以尝试并 取消阻止它们。

当检测到这样的请求时,其线程的当前堆栈跟踪 以 WARN 级别写入 Tomcat 日志。

您可以指定您希望请求花费的秒数,最大值(默认为 10 分钟!),如果超过此值,此 Valve 将关闭它们。

【讨论】:

  • 如果这是最好的方法,那就太可惜了——它看起来很脆弱。我真的希望有一种方法可以将一堆 IO 推送到 NIO 选择器线程上。
猜你喜欢
  • 1970-01-01
  • 2020-06-03
  • 1970-01-01
  • 2020-08-05
  • 2012-07-26
  • 1970-01-01
  • 2023-01-19
  • 1970-01-01
  • 2016-06-23
相关资源
最近更新 更多