C++和Java誰快？從算法上講我認爲毫無疑問是彙編〉C++〉Java，不要迷信某些個別評測，單純的迴圈測試什麼的，比如JNode的官方網站上有Java寫的JVM的性能和SUN的JVM
進行性能比較的結果，JNode中用Java寫的JVM竟然能比SUN公司用C++寫的JVM還快！編譯器完全可以作針對性優化影響測試結果，毫無意義的東西。而且，評測結果不會具備多少實際意義，真正的應用系統的效率是80%取決於整體的設計架構，而非你使用哪種語言。所以討論彙編、C++、Java誰更快這個問題的人恐怕更多是爲了自己的面子考慮，雖然Java當前如日中天，但其總是針對C++的批判性態度卻再明顯不過，所以Bruce纔會有“C++不垃圾，只是Java很傲慢”之說。
C++和Java根本的區別是什麼？我認爲毫無疑問是內存分配。編程思想和設計模式是活的東西，和語言沒有直接關係。Java沒有指針，C++寫程序也可以只用引用。JVM是Java在
內存管理上真正有別於C++的地方。JVM的好處是顯而易見的，跨平臺、更智能的內存管理，但能解決所有問題嗎，答案是否定的。
Java沒有內存泄露嗎?當然不是，我認爲java的內存泄露往往比C++更加難以排查，因爲JVM的緣故，程序員沒法直接對內存進行操控，隱患往往藏的更深。我曾經花了大量時間研究JVM的內存機制，雖然也有了不少心得，但直到現在仍然處於迷惑期。循環引用，緩存機制不合理，Spring等常態Bean的屬性重複加載都是可能喫內存的元兇。
對於一個單一的，低用戶低併發的系統，使用Java是很舒服的，程序員不用去考慮太多事情，照着業務邏輯做設計編代碼就行，不用管內存分配，不用管併發和互斥(其實還是要管的)，就算萬一有內存泄露的隱患，大不了每天重啓JVM一下就能解決了。但對於一個可能在多個應用環境中部署的軟件產品而言，內存泄露這種問題卻絕不能放過。我曾經遇到過在一個環境中運行非常良好，但在另一個環境中卻天天出問題的情況，即使每天重啓JVM也無濟於事。當時懷疑過很多方面，網絡、數據庫、容器等等。那時還不是很有概念，現在想起來還是後來好好看程序，優化了不少代碼，解決了幾個內存泄露，這樣才最終解決了不穩定的問題。舉例來講，在應用環境A中，服務器性能較好，JVM有2G內存，某個應用存在內存泄露的隱患，每次大約造成2M的內存消耗，這樣1000次左右就沒有內存可用了，就會造成JVM性能大幅降低。但在應用環境B中，服務器就沒那麼好的性能了，JVM僅有256M，那麼100多次操作就足以導致問題出現。而且，每個應用環境的應用使用率是不一樣的，在A中如果每天僅出現10次隱患應用操作，2-3個月都不會暴露問題，而且即使使用內存分析工具，開始階段也很難查出有無問題，但在B中，如果每天有100次隱患應用操作，只需一天問題就出現了。但實際應用過程中，應用的使用率往往很難精確統計的到，也無法預判，這也是造成問題排查困難的關鍵因素之一。應用環境的不確定性不單體現在地域上，也體現在時間上，不同時間的相同應用環境也不盡相同。挑選一個應用環境，常態性監測JVM的內存情況是避免這類問題發生的好辦法。
結論就是，對於中高端的產品化，多用戶，高併發應用，Java和C++一樣，不考慮內存是不可能的，畢竟語言最終操縱的還是計算機。
那Java的優勢在哪裏？我認爲其在中低端應用上的門檻更低。對大多數小型信息管理類系統而言，並不需要很嚴謹並且考慮周到的設計和編碼，學習java可以讓一個新手很快
上路，而C++卻沒有這種優勢，動不動就越界是新手常犯的錯誤。在一個通常的軟件團隊裏面，水平一定會有高低，而且也不是每個人都能通過學習進入深層次，這是C++難以解決的問題，Java在由於規範性方面的優勢更加適合新手使用。
C++就像手動檔汽車，Java更像自動檔，儘管越來越多人願意開自動檔，可是要想真正跑得快，賽車還得手動擋的。
問題出現總會讓人頭疼,追根溯源常常也會非常艱苦和漫長,但只要還有辦法,就不能放棄,規避問題可以解決陣痛,但永遠無法治根。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/chui88/archive/2011/04/18/6330408.aspx