java 当 WebContainer 线程池 (WebSphere) 被充分使用并收到新请求时会发生什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/31970542/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What happens when WebContainer thread pool (WebSphere) is fully used and new request is received?
提问by Michal123456
Got question about WebSphere and cannot find anything in the documentation...
有关于 WebSphere 的问题，但在文档中找不到任何内容...
What happens when WebContainer thread pool is fully used and new request is received? I am talking about the situation when all are used and we reached max thread pool size meaning that new one may not be created to process the request.
当 WebContainer 线程池被充分使用并收到新请求时会发生什么？我说的是当所有都被使用并且我们达到最大线程池大小时的情况，这意味着可能不会创建新的线程池来处理请求。
Will the request: - fail immediately and the response will contain some kind of error? - WAS will somehow "queue" the request for given period and process it when one of the threads is back in the pool? Some kind of error/timeout may still happen if the wait time is too long? - WAS will "queue" the request indefinitely and the timeout might only happen on the User side (web browser/app)?
请求是否会： - 立即失败并且响应将包含某种错误？- WAS 会以某种方式“排队”给定时间段的请求并在其中一个线程回到池中时处理它？如果等待时间太长，可能仍会发生某种错误/超时？- WAS 将无限期地“排队”请求并且超时可能只发生在用户端（网络浏览器/应用程序）？
回答by Brett Kail
The exact behavior is probably undocumented so that the details can be changed between releases in order to improve behavior. You can likely infer the behavior by looking at javacores or by gleaning information from various documents, for example the BoundedBuffer section of this IBM WebSphere Application Server Performance Cookbookdocument:
确切的行为可能没有记录，因此可以在版本之间更改细节以改进行为。您可以通过查看 javacore 或从各种文档中收集信息来推断行为，例如这个IBM WebSphere Application Server Performance Cookbook文档的 BoundedBuffer 部分：
The thread pool request buffer is essentially a backlog in front of the thread pool. If the thread pool is at its maximum size and all of the threads are dispatched, then work will queue in the requestBuffer. The maximum size of the requestBuffer is equal to the thread pool maximum size; however, if the unit of work is executed on the thread pool with a blocking mode of EXPAND_WHEN_QUEUE_IS_FULL_ERROR_AT_LIMIT or EXPAND_WHEN_QUEUE_IS_FULL_WAIT_AT_LIMIT, then the maximum size is ThreadPoolMaxSize * 10. When the requestBuffer fills up, then WSVR0629I is issued (although only the first time this happens per JVM run per thread pool). When the requestBuffer is full, work will either wait or throw a ThreadPoolQueueIsFullException, depending on how the unit of work is executed.
线程池请求缓冲区本质上是线程池前面的积压。如果线程池处于其最大大小并且所有线程都已分派，则工作将在 requestBuffer 中排队。requestBuffer 的最大大小等于线程池最大大小；但是，如果工作单元在阻塞模式为 EXPAND_WHEN_QUEUE_IS_FULL_ERROR_AT_LIMIT 或 EXPAND_WHEN_QUEUE_IS_FULL_WAIT_AT_LIMIT 的线程池上执行，则最大大小为 ThreadPoolMaxSize * 10。当 requestBuffer 填满时，WSVR0629每个线程池运行 JVM）。当 requestBuffer 已满时，工作将等待或抛出 ThreadPoolQueueIsFullException，具体取决于工作单元的执行方式。
In practice, that means after maxThreads threads are busy executing work, an additional maxThreads requests will be queued in a bounded buffer, and when that buffer is full, the socket thread will block until it can queue the work, which means that further incoming requests will be blocked until a thread becomes available and makes space in the bounded buffer.
实际上，这意味着在 maxThreads 线程忙于执行工作后，额外的 maxThreads 请求将在有界缓冲区中排队，当该缓冲区已满时，套接字线程将阻塞，直到它可以将工作排队，这意味着进一步传入的请求将被阻塞，直到线程可用并在有界缓冲区中腾出空间。
