※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
擁有後台管理系統的網站，將擁有強大的資料管理與更新功能，幫助您隨時新增網站的內容並節省網站開發的成本。
全身而退，是一種境界，更是一種智慧！編程，特別是框架設計，需要的就是哲學思維。“全身而退”這四個字，還在當年的內存泄露的踩坑過程中就悟出來了，有圖有真相：
有人會問，內存泄露和這個“全身而退”好像搭不上邊？從某些角度看也是，要不我不會單獨放在這裏講。但是也有一點關係，內存泄露不就是內存有分配沒有釋放，何時釋放，一般是程序退出之時。當年作為踩坑專業戶，踩過的坑遠遠不止前面有關“踩坑系列”系列文章提到的，可謂五花八門，也許可以套用一句話：“你們看到過的官場小說遠沒有我經歷過的精彩”：）大家可以看前面一系列踩坑經歷的總結。
當時踩過很多崩潰的坑，時不時的崩潰，我形容我當時是救火隊長。而當時經過不少的踩坑分析有一個共同的現象，竟然都是退出的時候，就莫名其妙崩潰了。然後這個問題其實也容易重現，你不停的啟動和退出就行了，至少百分之五十的概率。只是因為運行的時間不同，退出崩潰的堆棧還不一樣。
正是這樣子，我們總結開玩笑說，就是經不起折騰。也造就了後面，做項目時，寫完一個類，一定會測試退出。整個系統分不同的時間點反覆重啟、反覆插拔網線。基本達到着魔的程度，不是？原來我控制欲這麼強：）事實也證明了，經過這樣反覆重啟的折騰，新產品落地投入市場，基本沒有這些亂七八糟的問題了！踩坑經驗（二）有截圖作證：
很久才會出現一個Bug，而且也可以輕鬆搞定。一般都是新加的功能，或者很特別的情況沒考慮到。
所以，也通過真實的項目驗證了，全身而退的重要性。當然現在和當年的心境也完全不一樣了！事實上，後面經過分佈式洗禮，我的這種方法是正確的。分佈式就是解決這種單點故障。當然分佈式單點故障和單機故障，是不一樣的概念或者說屬性。分佈式中是考慮不可抗拒的原因，集群中單節點的穩定性肯定是集群穩定性的基礎。只是這種測試方法可以用來測試分佈式的故障切換，甚至是故障恢復！集群考慮的是集群的全身而退，事實上，我們在測試過程中也出現過集群整體失效的時候。
那麼我們可以從哪些方面去做到全身而退呢？下面我從實踐經驗中總結以下幾點。
一、單實例的使用
1.方式一
說到單實例，估計絕大部分人都說很簡單。如上的例子，一般的人會說沒問題。從邏輯來說確實沒問題，很簡單，不是嗎？實現類更簡單：
就一句話，靜態變量再申明一下。你是不是這樣實現的呢？ 這是我們重構的新平台上，依然有這樣使用的。以前的平台那就更多了，基本上是全部。導致的結果就是上面描述的崩潰就是家常便飯。當時在部門範圍內做培訓的時候，我把這個作為考題，結果能指出問題點的少之又少。
2.方式二
後面的修改：
這是定義，我們再看看具體實現：
平時我對代碼是追求簡潔的，但是在這裏我反而增加了函數，是不是看上去複雜了？No！簡潔必須建立在遵循原理的基礎之上。那為什麼要這麼改，遵循的原理是什麼？
最基本的原理就是單實例首先是一個對象，而且是類的對象，不是簡單變量。那麼類就可能涉及深拷貝，涉及到new和delete，比基礎變量要複雜得多。如果像第一種方式，那麼就可能出現編譯期間開始進行內存分配等操作，而退出的時候也在等着編譯器系統的自動回收。在這種啟動和退出之時非常容易操作已經不存在的對象和內存，而出現了崩潰。
其實，第一種方式使用的是靜態變量，可返回的是引用。從內存的布局而言，屬於系統（內核）管理，無法做到應用層的控制，面對複雜情況的內存使用很難做到全身而退。關於程序的內存布局和分配可以查閱虛擬技術和內存泄露兩篇文檔。
所以基於以上兩點，將單實例定義為類的私有變量，指針形式。那麼只有在程序啟動后要獲取的時候才開始構建類對象，完全可以掌控在自己（程序的用戶態）的手中，而且可以非常靈活的加入調試代碼，比如捕獲異常等。在程序退出之時，亦可以很方便很合理的選擇何時釋放和銷毀對象。
當然，一般編碼規範的公司就會直接用第二種方式，其他人使用的時候直接copy改改就行。同樣的如果是“先輩們”使用了第一種，錯誤也會傳承下去。。。而且大多時候錯誤的東西還很難糾正過來，就說第一種方式竟然被發現在代碼重構后！
所以，編程的時候我們需要有懷疑的精神、反思的精神和專業的引導！
二、架構設計
1.模塊與接口
模塊和層級清晰，接口簡單易用。都有利於全身而退。我們新版的存儲系統中，核心業務有三塊，IO+rewrite，而僅僅只有一個寫模塊I和rewrite模塊之間的接口！讀模塊O和其他都是完全分開。
2.類的五大函數
你聽說的都是類的三大函數吧，我這裏咋變成了五大函數，而且我的五大不是包括原來的三大。
2.1 構造函數和析構函數
只是單純的對成員變量進行賦值。
2.2 初始化函數和反初始化函數
例如內存的分配和釋放，多線程的創建啟動和停止。都應該放在這裏面，而不是上面提到的構造和析構中。在內存泄露中也提到過。其實只有一個目的，好控制！
2.3 複位函數
有異常情況下，不是被動退出，而是能夠主動控制，最壞的情況是複位。將各種變量、狀態、內存和多線程恢復到初始狀態。有的人可能會說，那怎麼不直接用初始化函數呢？這兩種功能還是不一樣的。初始化是系統啟動的時候用的。而複位可能承載更多的判斷，例如打印一些重要變量的信息，以利於開發人員跟蹤異常情況。
※別再煩惱如何寫文案,掌握八大原則!
什麼是銷售文案服務？A就是幫你撰寫適合的廣告文案。當您需要販售商品、宣傳活動、建立個人品牌，撰寫廣告文案都是必須的工作。
這五大函數是我建立一個類最基本的模板，也是做到全身而退基本的保障。
一個類要盡量做到職責單一，其實一個函數也是類似的。例如說初始化函數不能省，很多人將初始化和構造放一起，或者複位和初始化放一起。
析構函數只是簡單的初始化變量而已，而例如內存的分配、線程和定時器的啟動最好都到初始化函數中；
假如採用單例模式，則只需用到構造函數，像上面提到的單實例模式用的不好，如果構造函數中包括太多內存和多線程的使用，對退出將是一個災難。
而從另一個角度，虛擬內存的原理，內存只有分配和使用的時候才開始產生缺頁中斷即才開始尋找物理內存。所以何時初始化，何時使用內存可以掌握在開發人員的手中，而不是依賴系統來控制。
所以我認為這也是C++相比JAVA來說更好的優勢，可能有的人認為C++就是很難控制，像內存、指針、繼承，而且還沒有GC機制等等。而我認為剛剛相反，例如指針就是一把雙刃劍，你懂它，它就威力無窮！你看很多開源庫，比如經典的MySQL、高效的Redis、一直很火的Nginx，是吧，指針發揮了太大太大的作用，你能說這些庫不穩定嗎？雖然說我也一直關注和學習Java和Spring，主要學習它們的抽象思想！
3.鎖的設計
細心的你可以發現，上面單實例使用的第二種方式，加了一把鎖。我一般的類設計中，鎖的數量是2~3，大多情況下是2。單實例模式使用一把鎖，狀態機用一把鎖。在死鎖的踩坑經驗總結中曾經提到過，鎖的使用個數少，範圍少。所以你可以回頭看看狀態機和單實例模式鎖的使用。該加的時候一定加鎖，該不要加的時候一定不能加，不能模糊。
鎖或者說多線程同步使用不當，是很容易出問題的，不僅是運行過程中可能出現死鎖，退出的時候也可能出現，可能的情況就是退出失敗，同樣需要手動進行殺進程。
4.時序
前面的函數、接口、類、內存、多線程與鎖都設計好了，對於全身而退，或許已經成功了一半。還有一半在哪裡，時序。就是將這些對象和接口如何串起來，如果做到有序。最常見的是退出和啟動的順序即時序是相反的，這是基本的要求，而對於複雜的情況需要分兩方面來討論。
一方面，每個類、每個模塊都要做到全身而退，即每個類和模塊都需要有序的退出。所以上面類的設計，五大函數最終是為了全身而退，為了有序的釋放內存、停止線程等。我們上文提到的有限狀態機最終也是為了更好的控制線程、為了線程的退出，鎖的設計同樣可以減少干擾提高效率。所以系統的全身而退主要依賴於每個類、每個模塊的全身而退。
另一方面，程序最後的退出其實也是要封裝和集中在一兩個函數中，不能太散。即層級關係要非常明確，類似於樹的結構，最後集中到根節點，也就是一個函數。所以層級設計的目的也應該是，越到外層越好控制！
以上提到的幾點，包括時序，包括單實例模式，也包括最近一系列踩坑經歷，我最後都會歸納到框架或設計，所以也可以說這一切都是為了最終的全身而退。
總之，能隨時隨地的全身而退的代碼是一種境界，經得起各種折騰的代碼才是好代碼，經得起各種折騰的設計才是好的設計！
最後，萬事萬物的發展都離不開一個簡單的道理，例如讀一本書：
從簡單，到複雜，最後到簡單。但這兩個簡單的心境完全不一樣，前者我認為更多的是無知者無畏，後者則是一切瞭然於心。
計算機最終歸結於二進制的運算，最終就是01的組合，組合成各種數據結構和協議，組合成各種調度和算法，等等。
而對應於中國智慧，就是道，抓住事物的本質，以不變應萬變，陰陽論，太極八卦論；對應於中國的萬事開頭難，和全身而退！
也可以對應軟件兩大難點，就是原理的把握和框架的設計。
有了對原理的理解，能抓住事物的本質，就會下筆如有神助，也能最終全身而退！
當然你要達到這一點，得不停的”悟”！
悟的速度依賴”實踐+思考”！
肯定不能只依賴CRUD，也不能僅僅依賴改Bug的多少、僅僅依賴參与項目的多少。
有的改10個Bug比不上別人一個Bug，有的參与了10個項目不如比別人開發一個項目。
還是那句話，如果不讀書，行萬里路，也只是一個郵差。
所以，我認為多去“實踐+思考”。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
※教你寫出一流的銷售文案?
銷售文案是什麼？A文案是廣告用的文字。舉凡任何宣傳、行銷、販賣商品時所用到的文字都是文案。在網路時代，文案成為行銷中最重要的宣傳方式，好的文案可節省大量宣傳資源，達成行銷目的。