jvm垃圾回收

轉載http://pengjiaheng.iteye.com/blog/558619（若是侵權，聯繫刪除）

垃圾回收的悖論

    所謂「成也蕭何敗蕭何」。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實現之後，在這方面會有一個質的飛躍。

· Java 理論與實踐: 垃圾收集簡史

· Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning

· Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1

· Hotspot memory management whitepaper

· Java Tuning White Paper

· Diagnosing a Garbage Collection problem

· Java HotSpot VM Options

· A Collection of JVM Options

· Garbage-First Garbage Collection

· Frequently Asked Questions about Garbage Collection in the HotspotTM JavaTM Virtual Machine

· JProfiler試用手記

· Java6 JVM參數選項大全