Struts 1.x的线程安全_struts1 线程-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_38280568/article/details/104587870

第一轮做基础知识整理并没有那么深入，跳过了struts 1.x 的实例，一个完整的项目起码要有：

权限管理模块
安全加固模块-防入侵
UI web交互模块
业务层，业务逻辑封装模块
dao层数据处理模块–基础的是纯纯的JDBC
数据跟踪，异常干涉模块
入湖模块，OGG等是必不可少的，因为数据是企业命脉。

先简单的回顾，然后按需，第二轮，第三轮完善。

线程安全是每个多线程程序都要考虑的问题，Struts 1.x 也不理额外。如果处理不当就会出现问题，并且很难排查，设计阶段必须要留意线程安全。

软件设计应该优于开发，做HW系统最大的痛苦就是倒置，因为都是政治任务，每个人都只关注自己的或者自己团队的KPI，先做完再说，什么编码规范，设计模式，回归测试，关联影响都是跳空的，一切按照预来算。后期换供应商，供应商就要买单，因为一个系统试运营后，就会做代码扫描，安全扫描，性能测试，接手供应商就需要做义务整改，包含代码重构，性能优化等等。如果比较坑的连表设计都跳空胡搞，业务量上去，日志都写到表里，几万并发动不动锁表，一个表动不动几百G，你慢慢改吧，并且还是自动义务加班范畴，谁接手谁负责，非需求范围，不属于有效劳动。

IT产品都有一个规律，可维护性逐渐趋于0，如果有比较好的设计，面向接口设计，做好顶层设计，至少有一定的编码规范，注释规范，和持续维护的开发文档，符合开闭原则，和单一权责，其实系统比较好维护。当然打一枪换一个地方，来年这个产品还不知道那个团队做，另说。

这些都是外包的痛点，因为没有话语权，一切按照SE的性格来，一个喜欢做产品的SE，如果给你足够的PO，你的工作很轻松，因为有静态资产，后续可维护。
如果是一个能力比较强的SE,出了问题再说，综合实力很强不怕出问题，放弃一切设计，一句话需求直接做，然后要问题靠个人能力处理了。那么换过几波人，你就靠读代码能力，全力运维吧。

第一总情况，开发PO会多30%，因为要用于设计，考虑峰值未来业务扩展，至少不会崩盘。第二种情况，痛苦会多300%，因为业务扩展就不停的该源代码，当你发现一个JS几万行，业务并发量大的接收不了了，就会不停重构。选择第二种情况就是为了省钱，重构阶段基本是给你一半预算，然后是义务加班，例如HW小周末，每个晚上义务搞几个小时，加班打车自费，会然你爽的欲仙欲死。这都是公司基本财务问题，对个人而言，做这些毫无意义的事情，纯属浪费时间。

但是，对个人来说，要设计优于开发，不能功能实现再说。

1、 Action 是线程不安全的

Struts 1.x的Action 在生命周期上与Servlet 类似，Servlet由Tomcat容器产生并维护，而Action由Struts的ActionServlet产生并维护，每个Action都只有一个实例，在加载Struts时产生，在卸载Struts时销毁。

Struts用同一个Action的execute()方法来处理所有特定URI的请求。例如用HelloAction来处理/hello.do，用PersonAction来处理/person.do。这些请求共同使用同一个Action以及Action类属性等，因此Action与Servlet一样，都不是线程安全的。

由于Action是线程不安全的，因此要避免写Action的属性。最好的办法是把Action属性设置为final，禁止对其进行写操作，彻底避免线程不安全的问题。