java experience

• webservice接口拋出異常必定要用checked exception，最好不要用exception用resultdto
• 線程池不容許使用Executors去建立，而是經過ThreadPoolExecutor的方式，規避資源耗盡的風險。
• 高併發時，同步調用應該去考量鎖的性能損耗。能用無鎖數據結構，就不要用鎖；能鎖區塊，就不要鎖整個方法體；能用對象鎖，就不要用類鎖。
• 併發修改同一記錄時，避免更新丟失，要麼在應用層加鎖，要麼在緩存加鎖，要麼在數據庫層使用樂觀鎖，使用version做爲更新依據。說明：若是每次訪問衝突機率小於20%，推薦使用樂觀鎖，不然使用悲觀鎖。樂觀鎖的重試次數不得小於3次。
• 多線程場景下使用hashmap致使cpu高，可能不是本身寫的是引用第三方框架致使的，須要經過查看jstack日誌
• 不要強依賴緩存，須要縮短緩存超時時間，取不出來直接走db
• all inputs is evil,養成輸入數據過濾、輸出數據轉義的開發習慣
• 調用遠程操做必須有超時設置。HSF默認自動超時是3秒，相似於Httpclient的超時設置須要本身明確去設置Timeout
• 分佈式事務處理最大的問題是分佈式死鎖，基於等待圖的檢測不可伸縮性能也不可接受，超時則不及時。規避分佈式死鎖的好方法是統一順序，在事務涉及的節點已知時可完美處理，在涉及的節點須要動態擴時要經過時間戳來判斷是否違反順序，違反則restart
• 高併發服務器建議調小TCP協議的time_wait超時時間。
• 說明：操做系統默認240秒後，纔會關閉處於time_wait狀態的鏈接，在高併發訪問下，服務器端會由於處於time_wait的鏈接數太多，可能沒法創建新的鏈接，因此須要在服務器上調小此等待值。
• 正例：在linux服務器上請經過變動/etc/sysctl.conf文件去修改該缺省值（秒）：net.ipv4.tcp_fin_timeout = 30
• 調大服務器所支持的最大文件句柄數（File Descriptor，簡寫爲fd）。
• 說明：主流操做系統的設計是將TCP/UDP鏈接採用與文件同樣的方式去管理，即一個鏈接對應於一個fd。集團使用主流的linux服務器默認所支持最大fd數量爲1024，當併發鏈接數很大時很容易由於fd不足而出現「open too many files」錯誤，致使新的鏈接沒法創建。 建議將linux服務器所支持的最大句柄數調高數倍（與服務器的內存數量相關）。
• 給JVM設置-XX:+HeapDumpOnOutOfMemoryError參數，讓JVM碰到OOM場景時輸出dump信息。
• 說明：OOM的發生是有機率的，甚至有規律地相隔數月纔出現一例，出現時的現場信息對查錯很是有價值。