我们可以每次为 struts 1.x 动作类创建一个新实例吗？
struts 1.x 的操作类本质上不是线程安全的，因为 struts 会缓存操作类并将其用于其他请求。
有没有什么方法可以配置 struts 1.x 动作类，以便每次都创建动作类的新实例？
如果可以这样做，这样做有什么缺点吗？
The action classes of struts 1.x is inherently not thread safe since the struts caches the action classes and uses it for other requests too.
Is there any way we can configure struts 1.x action classes in such a way that a new instance of the action class is created each time ?
If it is possible to do so, are there any downsides to doing it ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最终，答案当然是肯定的：您可以获取 Struts 1 的完整源代码并将其扭曲成不希望的样子。
应该你吗？几乎可以肯定不是。如果您决定执行此操作，请从
RequestProcessor.processActionCreate开始。我同意布拉德，但会更强硬一些：你要做的事情是个坏主意。使用会话上下文、应用程序上下文、线程局部变量、同步等作为框架的预期用途。
通过超出框架的意图，您将面临大量您应该关注的技术风险。 Struts 1 中的没有使用每个请求的操作进行测试，因为框架不是这样构建的。它可能会起作用。它可能会惨败。它可能看起来好像正在工作。一阵子。直到它不是，然后你就完蛋了。
IMO 使用设计的框架会更有效。您想解决什么问题？可能有一个更好的解决方案，不需要至少一个完整的发布周期来审查修改后的框架的功能。
Ultimately, of course the answer is yes: you can get the complete source for Struts 1 and twist it into something it was not intended to be.
Should you? Almost certainly not. If you decide to undertake this, start with
RequestProcessor.processActionCreate.I'm with Brad, but would be a bit stronger: what you're going to try to do is a bad idea. Use session context, application context, thread locals, synchronization, etc. as the framework was intended to be used.
By moving outside the framework's intent, you open yourself up to an amount of technical risk that should concern you. Nothing in Struts 1 was tested with an action-per-request, because that's not how the framework was built. It may work. It may fail spectacularly. It may look like it's working. For awhile. Until it isn't, and you're screwed.
IMO it'd be more effective to use the framework as designed. What problem are you trying to solve? There's likely a better solution that wouldn't require at least a full release cycle to vet the modified framework's functionality.
不要这样做。正如您所说，它们不是线程安全的。
如果需要保存用户的状态，请将数据存储在数据库中，并将查找键值存储在用户的 HTTP_SESSION 中。如果（且仅当）您需要更好的性能，您可以引入缓存策略。
如果您尝试为每个请求存储一些数据，并且不想或不能使用 HTTP_SESSION，您可以考虑使用 ThreadLocal
Don't do it. As you've stated they're not thread safe.
If you need to hold state for the user, store the data in a database and a lookup key value in the user's HTTP_SESSION. If (and only if) you need better performance you can introduce a caching strategy.
If you're trying to store some data just for each single request, and don't want to or can't use the HTTP_SESSION, you could look at using ThreadLocal