Servlet 中的线程局部变量
线程局部变量对于向拥有该变量的 servlet 发出的所有请求来说是全局的吗？
我正在使用树脂作为服务器。
谢谢你的芒瑟。
我想我可以让自己更加清晰。
具体案例：
我想：
- 在请求开始执行时初始化一个静态变量。
- 能够以线程安全的方式在servlet调用的方法的进一步执行中查询变量的值，直到请求结束执行
Are the threadlocals variables global to all the requests made to the servlet that owns the variables?
I am using resin for the server.
Thanks for awnser.
I think I can make my self more clear.
The specific Case:
I want to:
- initialize a static variable when the request starts the execution.
- be able to query the value of the variable in the further executions of methods called from the servlet in a thread safety way until the request ends the execution
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
简短回答：是的。
更长一点：这就是 Spring 发挥其魔力的方式。 请参阅 RequestContextHolder （通过文档 Jar）。
但需要小心 - 您必须知道何时使 ThreadLocal 无效、如何推迟到其他线程以及如何（不）与非线程本地上下文纠缠在一起。
或者你可以只使用Spring...
Short answer: Yes.
A bit longer one: This is how Spring does its magic. See RequestContextHolder (via DocJar).
Caution is needed though - you have to know when to invalidate the ThreadLocal, how to defer to other threads and how (not) to get tangled with a non-threadlocal context.
Or you could just use Spring...
我认为它们对于仅使用该特定线程发出的所有请求都是全局的。 其他线程获取线程本地数据的其他副本。 这是线程本地存储的关键点：
http://en.wikipedia.org/wiki/Thread-local_storage#Java。
除非您在 servlet 配置中选中适当的选项，否则 servlet 容器将使用具有多个线程的 servlet 来并行处理请求。 因此，实际上，您将为为客户端提供服务的每个线程拥有单独的数据。
如果您的 Web 应用程序不是分布式的（在多个 Java 虚拟机上运行），您可以使用 ServletContext 对象来存储跨请求和线程的共享数据（然后确保执行适当的锁定）。
I think they are global to all requests made with that specific thread only. Other threads get other copies of the thread-local data. This is the key point of thread-local storage:
http://en.wikipedia.org/wiki/Thread-local_storage#Java.
Unless you check the appropriate option in the servlets config, the servlet container will use your servlet with multiple threads to handle requests in parallel. So effectively you would have separate data for each thread that's up serving clients.
If your WebApplication isn't distributed (runs on multiple Java Virtual Machines), you can use the
ServletContextobject to store shared data across requests and threads (be sure to do proper locking then).就像 Adiel 所说，执行此操作的正确方法可能是使用请求上下文（即 HttpServletRequest），而不是创建 ThreadLocal。 虽然这里当然可以使用 ThreadLocal，但如果这样做，您必须小心清理线程，否则获取该线程的下一个请求将看到与前一个请求关联的值。 （当线程完成第一个请求时，线程将返回到池中，因此下一个请求将看到它。）当请求上下文正是出于此目的而存在时，没有理由必须管理此类事情。
Like Adiel says, the proper way to do this is probably to use the request context (i.e. HttpServletRequest), not to create a ThreadLocal. While it's certainly possible to use a ThreadLocal here, you have to be careful to clean up your thread if you do that, since otherwise the next request that gets the thread will see the value associated with the previous request. (When the first request is done with the thread, the thread will go back into the pool and so the next request will see it.) No reason to have to manage that kind of thing when the request context exists for precisely this purpose.
如果您使用 Servlet 3.0 Suspendable requests（或 Jetty Continuations），使用 ThreadLocal 存储请求范围的信息可能会中断
使用这些 API 的多个线程处理单个请求。
Using ThreadLocal to store request scoped information has the potential to break if you use Servlet 3.0 Suspendable requests (or Jetty Continuations)
Using those API's multiple threads process a single request.
线程局部变量始终定义为可全局访问，因为重点是在可在任何地方访问的系统中透明地传递信息。 变量的值绑定到设置它的线程，因此即使该变量是全局变量，它也可以根据访问它的线程而具有不同的值。
一个简单的示例是，当 Servlet 中收到请求时，将用户身份字符串分配给线程局部变量中的线程。 沿着该请求的处理链的任何位置（假设它位于同一虚拟机中的同一线程上），都可以通过访问此全局变量来检索身份。 在处理请求时删除该值也很重要，因为线程将被放回到线程池中。
Threadlocal variables are always defined to be accessed globally, since the point is to transparently pass information around a system that can be accessed anywhere. The value of the variable is bound to the thread on which it is set, so even though the variable is global, it can have different values depending on the thread from which it is accessed.
A simple example would be to assign a user identity string to a thread in a thread local variable when the request is received in the servlet. Anywhere along the processing chain of that request (assuming it is on the same thread in the same VM), the identity can be retrieved by accessing this global variable. It would also be important to remove this value when the request is processed, since the thread will be put back in a thread pool.