垃圾回收的悖論
所謂“成也蕭何敗蕭何”。Java的垃圾回收確實帶來了很多好處，為開發帶來了便利。但是在一些高性能、高並發的情況下，垃圾回收 確成為了制約Java應用的瓶頸。目前JDK的垃圾回收算法，始終無法解決垃圾回收時的暫停問題，因為這個暫停嚴重影響了程序的相應時間 ，造成擁塞或堆積。這也是後續JDK增加G1算法的一個重要原因。
當然，上面是從技術角度出發解決垃圾回收帶來的問題，但是從系統設計方面我們就需要問一下了：
我們需要分配如此大的內存空間給應用嗎？
我們是否能夠通過有效使用內存而不是通過擴大內存的方式來設計我們的系統呢？
我們的內存中都放了什麼
內存中需要放什麼呢？個人認為，內存中需要放的是你的應用需要在不久的將來再次用到到的東西。想想看，如果你在將來不用這些東 西，何必放內存呢？放文件、數據庫不是更好？這些東西一般包括：
1.系統運行時業務相關的數據。比如web應用中的session、即時消息的session等。這些數據一般在一個用戶訪問周期或者一個使用過程 中都需要存在。
2.緩存。緩存就比較多了，你所要快速訪問的都可以放這裡面。其實上面的業務數據也可以理解為一種緩存。
3.線程。
因此，我們是不是可以這麼認為，如果我們不把業務數據和緩存放在JVM中，或者把他們獨立出來，那麼Java應用使用時所需的內存將會 大大減少，同時垃圾回收時間也會相應減少。
我認為這是可能的
解決之道
數據庫、文件系統
把所有數據都放入數據庫或者文件系統，這是一種最為簡單的方式。在這種方式下，Java應用的內存基本上等於處理一次峰值並發請求 所需的內存。數據的獲取都在每次請求時從數據庫和文件系統中獲取。也可以理解為，一次業務訪問以後，所有對象都可以進行回收了。
這是一種內存使用最有效的方式，但是從應用角度來說，這種方式很低效。
內存-硬盤映射
上面的問題是因為我們使用了文件系統帶來了低效。但是如果我們不是讀寫硬盤，而是寫內存的話效率將會提高很多。
數據庫和文件系統都是實實在在進行了持久化，但是當我們並不需要這樣持久化的時候，我們可以做一些變通——把內存當硬盤使。
內存-硬盤映射很好很強大，既用了緩存又對Java應用的內存使用又沒有影響。Java應用還是Java應用，他只知道讀寫的還是文件，但是 實際上是內存。
這種方式兼得的Java應用與緩存兩方面的好處。memcached的廣泛使用也正是這一類的代表。
同一機器部署多個JVM
這也是一種很好的方式，可以分為縱拆和橫拆。縱拆可以理解為把Java應用劃分為不同模塊，各個模塊使用一個獨立的Java進程。而橫 拆則是同樣功能的應用部署多個JVM。
通過部署多個JVM，可以把每個JVM的內存控制一個垃圾回收可以忍受的范圍內即可。但是這相當於進行了分布式的處理，其額外帶來的 復雜性也是需要評估的。另外，也有支持分布式的這種JVM可以考慮，不要要錢哦：）
程序控制的對象生命周期
這種方式是理想當中的方式，目前的虛擬機還沒有，純屬假設。即：考慮由編程方式配置哪些對象在垃圾收集過程中可以直接跳過，減 少垃圾回收線程遍歷標記的時間。
這種方式相當於在編程的時候告訴虛擬機某些對象你可以在*時間後在進行收集或者由代碼標識可以收集了（類似C、C++），在這之前你 即便去遍歷他也是沒有效果的，他肯定是還在被引用的。
這種方式如果JVM可以實現，個人認為將是一個飛躍，Java即有了垃圾回收的優勢，又有了C、C++對內存的可控性。
線程分配
Java的阻塞式的線程模型基本上可以拋棄了，目前成熟的NIO框架也比較多了。阻塞式IO帶來的問題是線程數量的線性增長，而NIO則可 以轉換成為常數線程。因此，對於服務端的應用而言，NIO還是唯一選擇。不過，JDK7中為我們帶來的AIO是否能讓人眼前一亮呢？我們拭目 以待。
其他的JDK
本文說的都是Sun的JDK，目前常見的JDK還有JRocket和IBM的JDK。其中JRocket在IO方面比Sun的高很多，不過Sun JDK6.0以後提高也很 大。而且JRocket在垃圾回收方面，也具有優勢，其可設置垃圾回收的最大暫停時間也是很吸引人的。不過，系統Sun的G1實現以後，在這方 面會有一個質的飛躍。
