容器100%控制它的线程。
如果您试图操纵容器的线程，那么您就是在打一场败仗。
无法安全地终止或停止正在运行的容器上的线程，因为这是非常不安全的，并且会导致许多内存问题（泄漏）和未关闭的资源。这个 Thread.stop() 方法自Java1.2以来一直被弃用。
既然我们已经排除了消极因素。。。
jetty是一个100%异步javaweb服务器。
一个请求使用一个线程的经典假设是错误的(如果你想要这种行为，那么你应该使用Jetty6或更老的。早于9.2的jetty版本现在都是eol/end of life）
当您使用传统上是阻塞调用的servlet调用时，jetty服务器必须伪造阻塞调用以满足api约定。
即使使用老式/传统的阻塞ServletAPI，您仍会遇到许多情况，在该请求的生命周期内，该请求已由多个线程处理。
如果您想使用servlet api及其容器，那么您应该做的第一件事就是开始同时使用servlet异步处理api和servlet异步i/oapi。请确保您阅读了这两个api上的gotchas！
异步处理将允许您在服务器端处理更多的请求处理，而不是大量使用容器线程，允许更多地控制线程的行为，允许您更好地控制请求超时，甚至可以收到您将始终在web服务器上处理的请求/响应错误情况的通知。
如果请求/连接中有要读取的内容或连接允许写入，异步i/o将只允许您使用线程。除非可以进行i/o，否则该连接不会占用线程。这意味着每台服务器有更多的连接/请求，而行为不正常的客户端（慢、死、有问题等）将不会通过使用对您没有任何效率的线程来影响其他客户端的行为。
如果您不想使用servlet api并以自己的方式进行操作，那么您必须管理自己的executor/threadgroup/threadpool，而服务器对此一无所知。但这仍然意味着您需要使用servlet异步处理API来允许2和谐共存（您需要使用asynccontext来通知容器您现在正在控制请求的处理，然后稍后通过asynccontext通知它您已经完成了请求，请求已经完成）。
这种方法最大的问题是，您无法从容器无法控制的线程安全地写入httpservletresponse。
意味着在线程上向应用程序调度容器，该线程是唯一可以安全地使用httpservletresponse来编写响应的线程。您可以让一个不同的线程进行处理，一个不同的线程向httpservletresponse提供数据，甚至一个不同的线程向dispatch线程提供内容。但是你被派往的那个线程需要用来写。
这是servlet规范中的混合线程行为（您处于servlet异步模式，在不同的线程上进行处理，但不使用异步模式进行读/写。）这是servlet规范中非常复杂且定义不清的行为，会导致许多问题，我建议您不要走这条路。
如果您还使用servlet异步i/oapi，那么这个问题就不存在了，但是在这一点上，上面两个选择中的差异可以忽略不计。