曾經遇到過性能問題嗎？ 我也是。 如果我的經理再喊一次“ faaaaster”，我一生都會有聽力障礙。 順便說一句，我能聽到所有聲音中的德語發音嗎？ ;-)

您可以相信仍然有人無知地在談論垃圾收集器（得到它嗎？）和JVM的性能。

……我將再次返回C語言，因此我不必擔心性能……

*嘆*

JVM一直在不斷改進其收集器算法，并且每個發行版中都將高度復雜的優化功能集成到了編譯器中（并且最近十年來一直在這樣做）。 您是否真的希望比世界上一些最聰明的人有經驗，能力和時間來編寫更好，更優化的C代碼？

Pleeeeease…

如果您像我一樣，其余99.99％的人，則明智的做法是忘記C。克服它。 （向所有核心C程序員致敬，不要被激怒）。

盡管我們的開發人員喜歡抽象，但我們不能否認它們天生就是泄漏的事實。 硬件*確實*很重要。 處理器數量和內存增長的趨勢使共享內存線程并發變得更加困難。 鎖定 ，上下文切換和線程調度可以使您的吞吐量等于糖漿，認為將更多線程倒入閃亮的新超級美容機中將以某種方式神奇地為您提供更多性能。 在某種程度上可能會，但這不是我的意思。

那么該怎么辦？ 我并沒有聲稱自己是一名性能專家，但我不是，但我有一些實用建議，至少可以幫助我解決過去一些討厭的性能錯誤。

1.編寫簡潔明了的代碼。 考慮使您的類不可變，它們是線程安全的，因此不需要同步，并且可以放心地對其進行緩存，以確保對象值在創建后不會更改。 不變性還導致代碼更易于理解。 不要嘗試使用過早的優化技巧來超越JVM。

Donald Knuth說： “程序員浪費大量時間來考慮或擔心程序非關鍵部分的速度，而這些效率的嘗試實際上在考慮調試和維護時會產生嚴重的負面影響。 我們應該忘記效率低下的問題，例如大約97％的時間：過早的優化是萬惡之源。 但是我們不應該放棄我們那關鍵的3％的機會。”

2.花一些時間了解不同垃圾收集器的工作方式。 信息有點分散，但是它在那里。 找到垃圾回收和您的應用程序之間的資源共享最有效點。 一般來說，較大的堆意味著垃圾收集器需要更努力地工作（竊取更多的CPU周期），并且暫停時間會更長，但頻率更低。 以我的經驗，即使使用CMS也無法避免世界停頓，因為最終您的堆將像瑞士奶酪一樣碎片化，并且繁榮， 內存碎片化失敗 。 好消息是，JDK7可能會包括一個名為G1的新的低暫停時間收集器，該收集器有可能完全避免世界停頓。 另請參閱Java 7中的垃圾優先收集器（G1） 。

3.在編程時，默認情況下始終使用java.util.concurrency 。 閱讀Java內存模型和線程規范 。 它將幫助您理解為什么您的代碼可能無法正常運行。 關于并發的主題也有很多不錯的書：

• 實踐中的Java并發
• 多處理器編程的藝術
• Java并發編程：設計原理和模式（第二版）

4.您可能正在處理具有粗糙粒度同步的舊代碼（您無法影響），從而導致高線程爭用。 將CPU親和力與同一臺機器上的多個JVM進程一起使用可以幫助減少對熱鎖的爭用。

5.如果您認為通過執行基準測試發現JVM性能問題，請首先確保您“知道”測量結果是準確的 。 如果您嘗試測量某些東西， 請不要測量其他東西 。 忽略此建議可能會使您誤以為是真正的問題所在。 因此，在開始測量之前，請確保正確隔離系統部件。

例如，如果您懷疑線程爭用，請查看ThreadInfo或嘗試jstat并查找sun.rt._sync_ContendedLockAttempts。

jstat -J-Djstat.showUnsupported=true -snap PID | grep _sync_

關于這個主題有太多話要說，但是我現在沒有時間寫更多。 編碼愉快！

參考： Deep Hacks博客上的JCG合作伙伴 KristofferSj?gren的 Usain Bolt看起來 不錯 。

相關文章 ：

• Java最佳實踐
• 如何在Java中獲得類似于C的性能
• 每個程序員應該了解的內存系統知識
• Java內存模型–快速概述和注意事項