回到首頁☞
先簡單的回顧，然後按需，第二輪，第三輪完善。
執行緒安全是每個多執行緒程式都要考慮的問題，struts 1.x 也不理額外。如果處理不當就會出現問題，並且很難排查，設計階段必須要留意執行緒安全。
軟體設計應該優於開發，做hw系統最大的痛苦就是倒置，因為都是政治任務，每個人都只關注自己的或者自己團隊的kpi，先做完再說，什麼編碼規範，設計模式，回歸測試，關聯影響都是跳空的，一切按照預來算。後期換**商，**商就要買單，因為乙個系統試運營後，就會做**掃瞄，安全掃瞄，效能測試，接手**商就需要做義務整改，包含**重構，效能優化等等。如果比較坑的連表設計都跳空胡搞， 業務量上去，日誌都寫到表裡，幾萬併發動不動鎖表，乙個表動不動幾百g，你慢慢改吧，並且還是自動義務加班範疇，誰接手誰負責，非需求範圍，不屬於有效勞動。
it產品都有乙個規律，可維護性逐漸趨於0，如果有比較好的設計，面向介面設計，做好頂層設計，至少有一定的編碼規範，注釋規範，和持續維護的開發文件，符合開閉原則，和單一權責，其實系統比較好維護。當然打一槍換乙個地方，來年這個產品還不知道那個團隊做，另說。
這些都是外包的痛點，因為沒有話語權，一切按照se的性格來，乙個喜歡做產品的se，如果給你足夠的po，你的工作很輕鬆，因為有靜態資產，後續可維護。
如果是乙個能力比較強的se,出了問題再說，綜合實力很強不怕出問題，放棄一切設計，一句話需求直接做，然後要問題靠個人能力處理了。那麼換過幾波人，你就靠讀**能力，全力運維吧。
第一總情況，開發po會多30%，因為要用於設計，考慮峰值未來業務擴充套件，至少不會崩盤。第二種情況，痛苦會多300%，因為業務擴充套件就不停的該源**，當你發現乙個js幾萬行，業務併發量大的接收不了了，就會不停重構。選擇第二種情況就是為了省錢，重構階段基本是給你一半預算，然後是義務加班，例如hw小週末，每個晚上義務搞幾個小時，加班打車自費，會然你爽的欲仙欲死。這都是公司基本財務問題，對個人而言，做這些毫無意義的事情，純屬浪費時間。
但是，對個人來說，要設計優於開發，不能功能實現再說。
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，禁止對其進行寫操作，徹底避免執行緒不安全的問題。
而struts 1.x的form bean 代表jsp表單，每次請求都會產生乙個新的form bean，不會出現多個執行緒共有乙個form bean的情況。因此，form bean是執行緒安全的，form bean中可任意地定義可讀寫的屬性。
struts 1.x 是action的單一例項節省了伺服器資源，算是乙個優點。但是由此帶來的執行緒不安全性卻為開發者帶來一些麻煩。struts 2.x action被設計成了多例模式，每個請求乙個action例項，請求完畢action就會銷毀。
回到首頁☞
struts1 x的Action執行緒安全問題
最近在幾個專案發現了struts 1.x的乙個安全性問題是值得注意的。以前一直沒有在意。因為過去的模式是前台頁面資料通過actionform傳入，action中的excute方法接收，這個問題是不存在的。但是，如果在action 中直接定義例項變數，問題就很大了。原因其實也很簡單 為了確保執行緒安全...
struts1 x 學習筆記
struts1.x 工作流程 2.建立actionform物件，儲存表單引數 3.使用actionform的validate方法進行引數驗證 4.actionservlet傳遞請求給相應的action 5.action的execute方法返回相應的actionforward物件 6.actionse...
struts 1 x 學習 筆記1
配置struts 1.x 要做的以下幾件事，1.匯入jar 2.web.xml配置actionservlet 3.struts conf.xml 4.配置formbean 5.配置action path 必須 type 必須 name 是frombean的名字 scope 作用域,只有session...