Struts2 线程中的拦截器不安全吗?

2022-01-16 00:00:00 thread-safety java struts2 interceptor

我知道 Struts2 Action 类是线程安全的，因为这些操作被放入了值堆栈中.值堆栈又是动作上下文的一部分.由于动作上下文是线程本地的，所以存储在动作上下文中的值(包括值堆栈)对于每个线程都是唯一的.所以，Action 是线程安全的.

但是考虑一下拦截器:它们真的很有用，它们为程序员完成了所有那些繁琐的小工作......比如验证、获取参数值等.但要考虑的是:拦截器可以在多个之间共享要求.那么这会使拦截器线程不安全吗?

带着这个问题，我尝试在网上浏览一些与这个问题相关的好文章.我发现了一篇非常好的文章，他们在其中明确提到了拦截器如何不是线程安全的示例.

网页是:http://www.bullraider.com/java/struts2/tutorials/interceptors-and-thread-safety

我从这篇文章中了解到，拦截器线程不安全的主要原因是拦截器只创建一次.即每个拦截器只有一个对象.因此，当一个Interceptor 的同一个实例在线程之间共享时，实例字段是不安全的.

在文章的最后提到，在某些情况下，即使是拦截器也是线程安全的.但他们没有提到任何此类案例.我上网寻找答案......但徒劳无功:(

谁能告诉我或提供一个链接，我可以在其中找到如何使拦截器线程安全(或者拦截器线程安全的场景是什么)?

解决方案

任何不使用实例字段或其他共享状态的Interceptor都是线程安全的:

例如，查看所有内置拦截器，用于解析 HTTP 请求参数和 cookie，进行日志记录、访问检查、异常处理:它们可以不使用可变状态的实例字段(*)，而只是对它们作为参数获得的 ActionInvocation 实例进行操作.

(*) 有些确实有配置参数的实例字段，这些参数在 Struts 启动时设置(在单个线程中)，例如 ExceptionMappingInterceptor，或线程安全的实例字段，如 Logger.xwork/xwork-core/2.3.1.1/com/opensymphony/xwork2/interceptor/LoggingInterceptor.java?av=h#60" rel="noreferrer">LoggingInterceptor.p>

如果您打算编写自己的 Interceptor，只需使用传入的 ActionInvocation 参数和 intercept() 中的局部变量方法.避免让你的拦截方法 synchronized 或将内容放入 synchronized{} 块中——这将给 Struts 的拦截器单实例方法造成瓶颈.

回答评论中的问题:

<块引用>(1) 为什么为每个线程创建一个动作实例不会影响性能?或者是吗?
使用现代 JVM，创建对象的成本可以忽略不计.如果您通过避免昂贵的初始化(例如通过不在操作内创建数据库连接，而是使用连接池.
<块引用>(2) 你是否建议永远不要使用默认的拦截器堆栈，并始终使用自定义拦截器堆栈(其中所有使用实例变量的未使用的拦截器都被删除)以便线程安全?
我认为 Struts 2 附带和配置的任何默认拦截器都不是线程安全的.即使它们使用实例字段(因为它们要么仅用于配置，要么本身是线程安全的，如 Logger).
根据我的个人经验，只有在有充分理由的情况下才应该触摸/更改拦截器堆栈(内置拦截器的线程安全性不是其中之一).如果您更改堆栈，很多事情都会以意想不到的方式运行/中断 - 从长远来看，运行default"或paramPrepareParam"等内置堆栈之一可以节省很多挫败感.添加您自己的自定义拦截器通常比从现有堆栈中删除/重新排列拦截器的破坏性更小.
I understand that Struts2 Action classes are thread-safe, because the actions are put in the Value Stack. The Value Stack in turn is one part of the Action Context. Since the Action Context is thread-local, the values stored in the Action Context (including the value stack) are unique per thread. So, Actions are thread-safe.

But consider the interceptors: They are really useful, they do all those tedious little jobs for the programmer... like validations, fetching the param values, etc. But the thing to consider is that: Interceptors can be shared between multiple requests. So does that make interceptors thread unsafe?

With this question in mind, I tried to surf the net for some good articles related to this problem. And I found a very good article, where they have clearly mentioned with an example How interceptors are NOT thread safe.

The web page is:  http://www.bullraider.com/java/struts2/tutorials/interceptors-and-thread-safety

What I got to know from this article is, the major reason behind Interceptors being thread un-safe is that the interceptors are created only once. i.e. each interceptor has only one object. So, the instance fields are not safe, when the same instance of an Interceptor is shared between threads.

At the end of the article it's mentioned that there are cases, where even the interceptors are thread safe. But they didn't mentioned any such cases. I surfed the net to find the answer... but in vain :(

Can anybody tell me or provide me with a link, where I can find out how to make interceptors thread-safe (or what are the scenarios when an interceptor is thread safe)?
 解决方案 Any Interceptor that does not use instance fields or other shared state is thread-safe:

For examples, look at all the built-in interceptors that parse HTTP request parameters and cookies, do logging, access checks, exception handling: They do not use instance fields for mutable state(*) but just operate on the ActionInvocation instance they get as parameters.

(*) some do have instance fields for configuration parameters which are set when Struts starts up (in a single thread), like ExceptionMappingInterceptor, or thread-safe instance fields like the Logger in LoggingInterceptor.

If you plan on writing your own Interceptor, work just with the ActionInvocation parameter you get passed in and with local variables in your intercept() method. Avoid the temptation to make your intercept method synchronized or put things into a synchronized{} block -- this will create a bottleneck with Struts' single-instance approach to Interceptors.

To answer the questions from the comments:

  (1) How come creating an instance of action for every thread doesn't affect the performance?or does it?
With modern JVMs, the cost of creating an object is negligible. There should be no noticeable effect on performance if you keep your actions light-weight by avoiding expensive initializtion, e.g. by not creating database connections inside an action but using a connection pool.

  (2) Do u recommend NEVER to use the default interceptor stack, and always use custom interceptor stack (where all the unused interceptors which use instance variables are removed) so that it will be thread safe?
I don't think any of the default interceptors that are shipped and configured with Struts 2 are not thread-safe; even if they use instance fields (because they're either used for configuration only or itself thread-safe like Logger).

From my personal experience, you should only ever touch/change the interceptor stack if you have a good reason (thread-safety of the built-in interceptors isn't one). A lot of things behave/break in unexpected ways if you change the stacks -- running one of the built-in stacks like "default" or "paramPrepareParam" saves a lot of frustration in the long run. Adding your own custom interceptors is usually less disruptive than removing/rearranging interceptors from an existing stack.


	
		相关文章