鄭昀 匯總 20130309

常見現象的故障分析： 現象倒推一：Java Web應用的連接數暴增 最大的可能是，Web應用的線程調用路徑中阻塞在某個遠端資源上。

• 線程向某個遠端資源發起的請求被阻塞，可能是以下原因：
  • 連接受阻，如等待client端連接池的空閑連接，如遠端服務連接數滿；
  • 響應遲遲沒有返回，如數據庫中的記錄被“表鎖”或“行鎖”，如數據庫有大量慢查詢；

常見的連接超時時間 為了讓大家一看到線上日志某些剛剛好的時間就能反應過來，總結如下：

• memcache
  • PHP下，Memcache::connect?函數傳入的 timeout 參數代表連接超時時間，單位秒。默認值1秒；
    • 注：修改此值之前請三思，過長的連接超時時間可能會導致失去所有的緩存優勢。?
  • Java下，
    • spymemcached 里，配置?opTimeout 代表操作超時時間，默認值2.5秒；
    • xmemcahced 里，opTimeout 的定義與spy 一樣，默認值1秒；
• mysql
  • wait_timeout：服務器關閉非交互連接之前等待活動的秒數，默認值28800秒（即8小時）；
  • connect_timeout：在獲取鏈接時，等待握手的超時時間，只在登錄時有效，默認值10秒；
  • innodb_lock_wait_timeout：一個 InnoDB 事務遇到一個行鎖，等待的超時時間，默認值50秒，屆時會打印“Lock wait timeout exceeded; try restarting transaction”錯誤；
• mongodb
  • Java下，
    • MongoOptions.maxWaitTime：連接上阻塞線程的最大等待時間，默認值120秒。
    • MongoOptions.connectTimeout：建立新連接超時時間， （注意Only used for new connections）?默認無限制。
    • MongoOptions.socketTimeout：socket通訊超時時間，默認無限制。

現象倒推二：Java應用頻繁 fullgc 頻繁 fullgc 大致有幾種原因： 第一種，還是由于某一個資源成為瓶頸，導致大量線程進入 blocked 狀態，新的 Requests 源源不斷進入，不斷開啟新線程。加之線程在內存中做了很多運算，且這些內存無法收回，導致 old generation（舊生代內存區）占用比例超過閾值（此閾值由 JVM 參數 CMSInitiatingOccupancyFraction設定，默認值是90%），進一步導致新對象分配沒有更多的空間，從而頻繁觸發 fullgc。 舉例，由于某段代碼沒有釋放數據庫連接——>連接池中的連接耗盡——>部分線程無限 TIMED_WAITING ——>其余線程都 Blocked——>開啟新線程——>頻繁引發GC——>占用大量CPU——>應用掛起。 第二種，產生了大量大內存對象，占用了大量堆空間，引發 fullgc 。 可以將當時的 memory dump 文件經由 MAT 工具分析，找到對應的對象或直接找到類。

---

語錄分享： 語錄： 『主動溝通，要求反饋：當你接到一個新的、沒有經驗的任務時，首先要確認目標、時間點等具體要求(what，why，when)；在有了做事的思路和框架時和老板溝通，獲取反饋(how)；在初稿完成后再次溝通獲取反饋；最后才是最終成果。切忌自己悶頭做到最后的時間點，此時如果結果不符合預期會很被動。』——Qiaoxin 語錄： 『上周和兄弟們飯后百步走，隨口一句：組織是什么？組織就是屁股。組織架構就是擺屁股，架構調整就是調整屁股。因屁股造成事情辦不妥，推進不了。就該時候動手了。』——carnec 語錄： 『早期項目一看團隊，二看方向，但都需要打得贏。團隊希望是一起打過仗的，立過戰功的，有基本的默契，這樣的團隊繼續贏的概率更大。方向打得贏則是指所在方向有大概率打得贏，至少能先站住，后站高。』——林軍 語錄： 『我選領導團隊的四個原則：一是必須有理想有事業心有共同的價值觀；二是個人能力一定要互補，不能都找能力和你相似的人，個人可以有不足，團隊不能有短板；三是每個人要有獨立作戰獨擋一面獨立發展的能力，有這樣的團隊公司才能有發展空間；四是我管的團隊不能太多人，喝酒時一桌一定要都坐得下。 』——孫宏斌 語錄： 『曾在一處見到，淘寶在長期使用java構建web項目后，得出一個結論：積重難返。 實際工作經驗得到的結論，積重難返的原因，往往不是java本身的緣故，而是團隊成員基礎積累參差不齊，許多次的“一不小心”積累成了最終的結果。到了悔之晚矣的時候自然就積重難返了。如何避免java使用自傷，最關鍵在于，統一團隊成員的code入口，框下可能發生的事情，避開不能發生的事情』——54chen 語錄： 『有人說「臺風來的時候，豬都能飛起來」，公司快速成長期，每個人好像都能力都倍增，其實沒有，大形勢好，濫竽充數也能像個高手，所以這時候千萬別忽視個人學習，否則大潮退去，越在浪頭上越死在沙灘上。』——Fenng 語錄『幾乎每個工程師都能挑出discuz的若干不足和問題，有時候我就會從中選擇一些面試題，比如discuz在ip地區識別中的一些算法函數，一些復合索引和冗余字段的設計思路，乃至用戶密碼隨機salt的原理，一深究下去，發現應聘者基本上都回答不出來。』——caoz 語錄： 『【CEO必鑒：爛蘋果定律】在任何組織里，都存在幾個難管理的人物，他們像蘋果箱里的爛蘋果，如果你不及時處理，它會迅速傳染，把果箱里其他蘋果也弄爛。一個不干工作，喜歡搬弄是非的人足以很快將一個高效的部門變成一盤散沙。“爛蘋果”要果斷清除！』——正和島標準 語錄： 『擔當、責任意識和自動補位是創業團隊早期必要的。而不是經常說這不是我的事、我不是管事的、需要找xxx……從0-1，從1-10，只有敢于要，敢于擔當的人最后才能成為獲得成就、地位、認可的人』——文昭武穆 語錄： 『你遇到過很多聰明人，你的大學同學，你的同事，你的朋友，有幾個比你傻？很多年以后，你會看到成功的并不是最聰明的人。因為決定成功的更多是非智力因素：明確的目標，積極的心態，努力和堅持，承受挫折和壓力的能力，成熟的接人待物等等。有一種人注定沒戲：不努力和怨天尤人。』——孫宏斌 語錄： 『我以為，工資的定價依據，不是自己在其他地方能拿多少，而是公司花多少錢可以招到替代自己的人。』 ——鄧熔 語錄： 『 @孫陶然：#昆侖的侖# 一把手要對進度敏感，盯住KPI，把精力放在解決那些未達成KPI的部門上。解決問題時先看人再看事兒，人對了事兒才可能對，人不對事兒不可能對。 』 語錄： 『越是在最緊要的時刻，越是考驗團隊：哪些人可以拉得出、扛得上；哪些人怯陣、退縮；哪些人是真正的頂梁柱，哪些人是打醬油的。請每一位想在職場上不斷取得更好發展的人都要格外珍惜這樣的機會，充分施展自己的才能，在關鍵時刻發揮關鍵作用，這種機會不是想有就有，甚至可能不是由團隊左右，切忌掉隊。 ——sodme』 語錄： 『 @許曉輝 ：在創業公司，不會主動找事做的人，不是原地踏步，就是會被淘汰。主動找事首先是基于本職崗位的創新和實踐（這一點大多數人做不到），其次是對自己所處工作鏈條的完善（不必顧慮是否跨界），最后是對公司各環節的觀察、思考與建議（做到這一層離晉級就不遠了）。第一點最重要，有了根據地才好擴張疆域。 』 語錄： 『@許曉輝： 曾經不理解老板變化無常，定下來的事怎么說變就變；等你自己做老板會發現：局勢總在變化，必須隨時做出調整，以應對來襲的風浪，確保航行安全。若你在創業公司，更要深刻理解這一點，理解變化背后的緣由。自此，我也深刻領會了馬云的話：“真正的高手還在于制造變化，在變化來臨之前變化自己。” 』 語錄： @許曉輝 ：對于跳槽頻繁者（在一家公司時間低于一年）一定要謹慎，此類人大部分不是能力就是態度有問題。你不能指望自己有點石成金的魔法，也不能指望一個缺乏耐力的人能在你公司變得堅韌不拔，他可能只是以跳槽逃避困難與壓力。?

轉載于:https://www.cnblogs.com/zhengyun_ustc/archive/2013/03/29/2989308.html

總結

以上是生活随笔為你收集整理的Java两则故障分析和常见连接超时时间的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。