一、基於JVM的大資料生態圈

1.bigdata on jvm

1.現在大多數開源大資料處理框架都是基於jvm的，像 Apache Hadoop,Apache Spark,Apache Hbase,
  Apache Kafka,Apache Flink等。
2.JVM上的程式一方面享受著它帶來的好處，也要承受著JVM帶來的弊端。

2.jvm的弊端

1.JVM的OOM問題
利用JVM平臺開發的程式都會受到OutOfMemoryError的困擾，特別是大資料領域分散式計算框架，他們需要大量的記憶體，
不得不經常面臨這個頭疼的問題，當JVM中所有物件大小超過分配給JVM的記憶體大小時，就會發生OutOfMemoryError錯誤，
導致JVM崩潰，所有在JVM上工作的程式都將無一倖免的受到影響。

2.
 
Full GC 
JVM的GC機制一直都是讓人又愛又恨的東西。一方面，JVM自己管理記憶體，減輕開發者的負擔，提高開發效率，保障記憶體安全。
另一方面，不受開發者控制的GC想一顆定時炸彈一樣，一旦JVM進行大規模的垃圾回收，所有基於jvm的程式都不再工作，這將
極大的影響實時應用的可靠交付。特別是大資料領域，在處理大量資料的時候，不可避免的的建立了大量的臨時物件，一旦物件
使用完畢後，JVM就不定期的進行大規模的垃圾回收工作，這對大資料應用影響很大。

3.Java物件儲存密度低
例一：一個只包含boolean屬性的物件佔用了16個位元組記憶體：物件頭佔了8個，boolean 屬性佔了1個，對齊填充佔了7
 
個。
而實際上只需要一個bit（1/8位元組）就夠了。
例二：“abcd”這樣簡單的字串在UTF-8編碼中需要4個位元組儲存，但Java採用UTF-16編碼儲存字串，需要8個位元組儲存
“abcd”，同時Java物件還物件header等其他額外資訊，一個4位元組字串物件，在Java中需要48位元組的空間來儲存。
對於大部分的大資料應用，記憶體都是稀缺資源，更有效率的記憶體儲存，則意味著CPU資料訪問吞吐量更高，及更少的磁碟落地。

注意：

現在很多大資料處理引擎，開始自動動手管理記憶體。比如 Apache Drill,Apache Ignite,Apache Geode,Apache Spark等。