Multithreading with Jersey(Jersey 多线程)
问题描述
这里有两个似乎相互矛盾的链接.我宁愿相信文档:
Here are two links which seem to be contradicting each other. I'd sooner trust the docs:
链接 1
服务器上的请求处理默认以同步处理模式工作
Request processing on the server works by default in a synchronous processing mode
链接2
它已经是多线程的了.
我的问题:
这是正确的.可以同步多线程吗?
Which is correct. Can it be both synchronous and multithreaded?
为什么文档会这样说?:
Why do the docs say the following?:
在已知资源方法执行需要很长时间才能计算结果的情况下,应使用服务器端异步处理模型
in cases where a resource method execution is known to take a long time to compute the result, server-side asynchronous processing model should be used
如果文档正确,为什么默认操作是同步的?为了用户体验,默认情况下所有请求在客户端 JavaScript 上都是异步的,因此服务器端的默认操作也应该是异步的.
If the docs are correct, why is the default action synchronous? All requests are asynchronous on client-side javascript by default for user experience, it would make sense then that the default action for server-side should also be asynchronous too.
如果客户端不需要按特定顺序处理请求,那么谁在乎操作有多昂贵".不应该所有操作都是异步的吗?
If the client does not need to serve requests in a specific order, then who cares how "EXPENSIVE" the operation is. Shouldn't all operations simply be asynchronous?
推荐答案
服务器上的请求处理默认以同步处理模式工作
Request processing on the server works by default in a synchronous processing mode
每个请求都在单独的线程上处理.该请求被认为是同步的,因为该请求会一直占用线程,直到请求完成处理.
Each request is processed on a separate thread. The request is considered synchronous because that request holds up the thread until the request is finished processing.
它已经是多线程的了.
是的,服务器(容器)是多线程的.对于传入的每个请求,都会从线程池中取出一个线程,并将请求绑定到特定的请求.
Yes, the server (container) is multi-threaded. For each request that comes in, a thread is taken from the thread pool, and the request is tied to the particular request.
在已知资源方法执行需要很长时间才能计算结果的情况下,应使用服务器端异步处理模型
in cases where a resource method execution is known to take a long time to compute the result, server-side asynchronous processing model should be used
是的,这样我们就不会阻塞容器线程.容器线程池中处理请求的线程只有这么多.如果我们用长的处理请求来拖住它们,那么容器可能会耗尽线程,阻止其他请求进入.在异步处理中,Jersey 将线程交还给容器,并自行处理请求处理线程池,直到进程完成,然后将响应发送到容器,容器可以将其发送回客户端.
Yes, so that we don't hold up the container thread. There are only so many threads in the container thread pool to handle requests. If we are holding them all up with long processing requests, then the container may run out of threads, blocking other requests from coming in. In asynchronous processing, Jersey hands the thread back to the container, and handle the request processing itself in its own thread pool, until the process is complete, then send the response up to the container, where it can send it back to the client.
如果客户端不需要按特定顺序处理请求,那么谁在乎操作有多昂贵".
If the client does not need to serve requests in a specific order, then who cares how "EXPENSIVE" the operation is.
不确定客户与这里的任何事情有什么关系.或者至少在你如何提出问题的背景下.对不起.
Not really sure what the client has to do with anything here. Or at least in the context of how you're asking the question. Sorry.
所有操作不应该都是异步的吗?
Shouldn't all operations simply be asynchronous?
不一定,如果所有请求都很快.尽管您可以为此提出论据,但这需要性能测试,并且您可以相互对比并从中做出决定的数字.每个系统都是不同的.
Not necessarily, if all the requests are quick. Though you could make an argument for it, but that would require performance testing, and numbers you can put up against each other and make a decision from there. Every system is different.
这篇关于Jersey 多线程的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:Jersey 多线程
基础教程推荐
- 在 Libgdx 中处理屏幕的正确方法 2022-01-01
- 设置 bean 时出现 Nullpointerexception 2022-01-01
- 无法使用修饰符“public final"访问 java.util.Ha 2022-01-01
- 减少 JVM 暂停时间 >1 秒使用 UseConcMarkSweepGC 2022-01-01
- 如何使用 Java 创建 X509 证书? 2022-01-01
- 降序排序:Java Map 2022-01-01
- Java Keytool 导入证书后出错,"keytool error: java.io.FileNotFoundException &拒绝访问" 2022-01-01
- Java:带有char数组的println给出乱码 2022-01-01
- FirebaseListAdapter 不推送聊天应用程序的单个项目 - Firebase-Ui 3.1 2022-01-01
- “未找到匹配项"使用 matcher 的 group 方法时 2022-01-01