我眼中的效能劣化、優化的曲線

效能劣化

隨著程式碼寫得越來越爛，程式執行時 資料庫操作更多、IO 阻塞等待跟過、不必要的物件建立、GC 回收更頻繁，執行緒的上下文切換也更多，開銷越來越多，所有因素綜合起來，程式執行更慢，響應延遲加大。

當到達臨界點的時候，壓垮駱駝的最後一根稻草出現了，系統直接崩潰。

壞東西、副作用是會累積的。

效能優化

程式碼的實現一直保持良好，不斷通過 合併查詢等措施減少資料庫操作，通過優化SQL語句縮短了單次資料庫操作的時間，通過更好的日誌記錄方式減少 IO 操作，減少 IO 阻塞等待的時間，進而又可以減少執行緒切換的次數，通過避免不必要的物件建立，可以提升程式碼的執行速度，還可以減少 GC 的次數，種種優化效果綜合起來的結果就是程式執行穩定，響應時間縮短。

從業務實現的角度進行優化的效果是很明顯的。

當然，到達臨界點之後，也就是沒法從業務實現的方式上優化效能的時候，只能通過更底層、更細微的優化手段進行優化，比如 JVM 引數、系統引數 調優等，這些措施帶來的效果都是不怎麼明顯的。

比如，業務實現減少一次資料庫操作，至少可以減少 10ms 的延遲，但要在更底層的地方得到 10ms 的優化效果應該是很困難的。

正面的作用也是可以累積的，只不過幅度是很緩慢的，且達到一定程度就很難再繼續提升了。

作為開發人員，應該重視每一個細節。