A. 如何調整java虛擬機內存大小
在一些規模稍大的應用中，Java虛擬機（JVM）的內存設置尤為重要，想在項目中取得好的效率，GC（垃圾回收）的設置是第一步。
PermGen space：全稱是Permanent Generation space.就是說是永久保存的區域,用於存放Class和Meta信息,Class在被Load的時候被放入該區域Heap space：存放Instance。
GC(Garbage Collection)應該不會對PermGen space進行清理,所以如果你的APP會LOAD很多CLASS的話,就很可能出現PermGen space錯誤
Java Heap分為3個區
1.Young
2.Old
3.Permanent
Young保存剛實例化的對象。當該區被填滿時，GC會將對象移到Old區。Permanent區則負責保存反射對象，本文不討論該區。
JVM的Heap分配可以使用-X參數設定，
-Xms
初始Heap大小
-Xmx
java heap最大值
-Xmn
young generation的heap大小
JVM有2個GC線程
第一個線程負責回收Heap的Young區
第二個線程在Heap不足時，遍歷Heap，將Young 區升級為Older區
Older區的大小等於-Xmx減去-Xmn，不能將-Xms的值設的過大，因為第二個線程被迫運行會降低JVM的性能。
為什麼一些程序頻繁發生GC？
有如下原因：
1.程序內調用了System.gc()或Runtime.gc()。
2.一些中間件軟體調用自己的GC方法，此時需要設置參數禁止這些GC。
3.Java的Heap太小，一般默認的Heap值都很小。
4.頻繁實例化對象，Release對象 此時盡量保存並重用對象，例如使用StringBuffer()和String()。
如果你發現每次GC後，Heap的剩餘空間會是總空間的50%，這表示你的Heap處於健康狀態,許多Server端的Java程序每次GC後最好能有65%的剩餘空間
經驗之談：
1．Server端JVM最好將-Xms和-Xmx設為相同值。為了優化GC，最好讓-Xmn值約等於-Xmx的1/3。
2．一個GUI程序最好是每10到20秒間運行一次GC，每次在半秒之內完成。
注意：
1．增加Heap的大小雖然會降低GC的頻率，但也增加了每次GC的時間。並且GC運行時，所有的用戶線程將暫停，也就是GC期間，Java應用程序不做任何工作。
2．Heap大小並不決定進程的內存使用量。進程的內存使用量要大於-Xmx定義的值，因為Java為其他任務分配內存，例如每個線程的Stack等。
Stack的設定
每個線程都有他自己的Stack。
-Xss
每個線程的Stack大小
Stack的大小限制著線程的數量。如果Stack過大就好導致內存溢漏。-Xss參數決定Stack大小，例如-Xss1024K。如果Stack太小，也會導致Stack溢漏。
硬體環境
硬體環境也影響GC的效率，例如機器的種類，內存，swap空間，和CPU的數量。
如果你的程序需要頻繁創建很多transient對象，會導致JVM頻繁GC。這種情況你可以增加機器的內存，來減少Swap空間的使用。
4種GC
1、第一種為單線程GC，也是默認的GC，該GC適用於單CPU機器。
2、第二種為Throughput GC，是多線程的GC，適用於多CPU，使用大量線程的程序。第二種GC與第一種GC相似，不同在於GC在收集Young區是多線程的，但在Old區和第一種一樣，仍然採用單線程。-XX:+UseParallelGC參數啟動該GC。
3、第三種為Concurrent Low Pause GC，類似於第一種，適用於多CPU，並要求縮短因GC造成程序停滯的時間。這種GC可以在Old區的回收同時，運行應用程序。-XX:+UseConcMarkSweepGC參數啟動該GC。
4、第四種為Incremental Low Pause GC，適用於要求縮短因GC造成程序停滯的時間。這種GC可以在Young區回收的同時，回收一部分Old區對象。-Xincgc參數啟動該GC。
單文件的JVM內存進行設置
默認的java虛擬機的大小比較小，在對大數據進行處理時java就會報錯：java.lang.OutOfMemoryError。
設置jvm內存的方法，對於單獨的.class，可以用下面的方法對Test運行時的jvm內存進行設置。
java -Xms64m -Xmx256m Test
-Xms是設置內存初始化的大小
-Xmx是設置最大能夠使用內存的大小（最好不要超過物理內存大小）
tomcat啟動jvm內存設置
Linux：
在/usr/local/apache-tomcat-5.5.23/bin目錄下的catalina.sh添加：JAVA_OPTS='-Xms512m -Xmx1024m'要加「m」說明是MB，否則就是KB了，在啟動tomcat時會報內存不足。
-Xms：初始值
-Xmx：最大值
-Xmn：最小值Windows
在catalina.bat最前面加入
set JAVA_OPTS=-Xms128m -Xmx350m 如果用startup.bat啟動tomcat,OK設置生效.夠成功的分配200M內存.但是如果不是執行startup.bat啟動tomcat而是利用windows的系統服務啟動tomcat服務,上面的設置就不生效了,就是說set JAVA_OPTS=-Xms128m -Xmx350m 沒起作用.上面分配200M內存就OOM了..windows服務執行的是bin\tomcat.exe.他讀取注冊表中的值,而不是catalina.bat的設置.解決辦法:
修改注冊表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat Service Manager\Tomcat5\Parameters\JavaOptions
原值為
-Dcatalina.home="C:\ApacheGroup\Tomcat 5.0"
-Djava.endorsed.dirs="C:\ApacheGroup\Tomcat 5.0\common\endorsed"
-Xrs加入 -Xms300m -Xmx350m
重起tomcat服務,設置生效
weblogic啟動jvm內存設置
在weblogic中，可以在startweblogic.cmd中對每個domain虛擬內存的大小進行設置，默認的設置是在commEnv.cmd裡面。
JBoss
默認可以使用的內存為64MB
$JBOSSDIR$/bin/run.config
JAVA_OPTS = "-server -Xms128 -Xmx512"
Eclipse
在所在目錄下，鍵入
eclipse.exe -vmargs -Xms256m -Xmx512m
256m表示JVM堆內存最小值
512m表示JVM堆內存最大
Websphere
進入控制台去設置：應用程序伺服器 > server1 > 進程定義 > Java 虛擬機
B. elasticsearch java 怎麼設置 ignore
Elasticsearch對Java虛擬機進行了預先的配置。通常情況下，因為這些配置的選擇還是很謹慎的，所以你不需要太關心，並且你能立刻使用ElasticSearch。
但是，當你監視ElasticSearch節點內存時，你可能嘗試修改一些配置。這些修改是否會改善你的處境？
這篇博文嘗試揭開Elasticsearch配置的神秘面紗，並且討論最常見的調整。最終，會給出一些推薦的配置調整。
Elasticsearch JVM 配置概覽：
這些是Elasticsearch 0.19.11版本的默認配置。
JVM參數 Elasticsearch默認值 Environment變數
-Xms 256m ES_MIN_MEM
-Xmx 1g ES_MAX_MEM
-Xms and -Xmx ES_HEAP_SIZE
-Xmn ES_HEAP_NEWSIZE
-XX:MaxDirectMemorySize ES_DIRECT_SIZE
-Xss 256k
-XX:UseParNewGC +
-XX:UseConcMarkSweepGC +
-XX: 75
-XX:UseCMSInitiatingOccupancyOnly +
-XX:UseCondCardMark (commented out)
首先你注意到的是，Elasticsearch預留了256M到1GB的堆內存。
這個設置適用於開發和演示環境。開發人員只需要簡單的解壓發行包，再執行./bin/elasticsearch -f就完成了Elasticsearch的安裝。當然這點對於開發來說非常棒，並且在很多場景下都能工作，但是當你需要更多內存來降低Elasticsearch負載的時候就不行了，你需要比2GB RAM更多的可用內存。
ES_MIN_MEM/ES_MAX_MEM是控制堆大小的配置。新的ES_HEAP_SIZE變數是一個更為便利的選擇，因為將堆的初始大小和最大值設為相同。也推薦在分配堆內存時盡可能不要用內存的碎片。內存碎片對於性能優化來說非常不利。
ES_HEAP_NEWSIZE是可選參數，它控制堆的子集大小，也就是新生代的大小。
ES_DIRECT_SIZE控制本機直接內存大小，即JVM管理NIO框架中使用的數據區域大小。本機直接內存可以被映射到虛擬地址空間上，這樣在64位的機器上更高效，因為可以規避文件系統緩沖。Elasticsearch對本機直接內存沒有限制(可能導致OOM)。
由於歷史原因Java虛擬機有多個垃圾收集器。可以通過以下的JVM參數組合啟用：
JVM parameter Garbage collector
-XX:+UseSerialGC serial collector
-XX:+UseParallelGC parallel collector
-XX:+UseParallelOldGC Parallel compacting collector
-XX:+UseConcMarkSweepGC Concurrent-Mark-Sweep (CMS) collector
-XX:+UseG1GC Garbage-First collector (G1)
UseParNewGC和UseConcMarkSweepGC組合啟用垃圾收集器的並發多線程模式。UseConcMarkSweepGC自動選擇UseParNewGC模式並禁用串列收集器（Serial collector）。在Java6中這是默認行為。
提煉了一種CMS（Concurrent-Mark-Sweep）垃圾收集設置；它將舊生代觸發垃圾收集的閥值設為75.舊生代的大小是堆大小減去新生代大小。這告訴JVM當堆內容達到75%時啟用垃圾收集。這是個估計的值，因為越小的堆可能需要越早啟動GC。
UseCondCardMark將在垃圾收集器的card table使用時，在marking之前進行額外的判斷，避免冗餘的store操作。UseCondCardMark不影響Garbage-First收集器。強烈推薦在高並發場景下配置這個參數（規避card table marking技術在高並發場景下的降低吞吐量的負面作用）。在ElasticSearch中，這個參數是被注釋掉的。
有些配置可以參考諸如Apache Cassandra項目，他們在JVM上有類似的需求。
總而言之，ElastciSearch配置上推薦：
1. 不採用自動的堆內存配置，將堆大小默認最大值設為1GB
2.調整觸發垃圾收集的閥值，比如將gc設為75%堆大小的時候觸發，這樣不會影響性能。
3.禁用Java7默認的G1收集器，前提是你的ElasticSearch跑在Java7u4以上的版本上。
JVM進程的內存結果
JVM內存由幾部分組成：
Java代碼本身：包括內部代碼、數據、介面，調試和監控代理或者位元組碼指令
非堆內存：用於載入類
棧內存：用於為每個線程存儲本地變數和操作數
堆內存：用於存放對象引用和對象本身
直接緩沖區：用於緩沖I/O數據
堆內存的大小設置非常重要，因為Java的運行依賴於合理的堆大小，並且JVM需要從操作系統那獲取有限的堆內存，用於支撐整個JVM生命周期。
如果堆太小，垃圾回收就會頻繁發生，發生OOM的幾率會很大。
如果堆太大，垃圾回收會延遲，但是一旦回收，就需要處理大量的存活堆數據。並且，操作系統的壓力也會變大，因為JVM進程需要更大的堆，產生換頁的可能性就會提高。
注意，使用CMS垃圾收集器，Java不會把內存還給操作系統，因此配置合理的堆初始值和最大值就非常重要。
非堆內存由Java應用自動分配。沒有什麼參數控制這里的大小，這是由Java應用程序代碼自己決定的。
棧內存在每個線程中分配，在Elasticsearch中，每個線程大小必須由128K增加到256K，因為Java7比Java6需要更大的棧內存 ，這是由於Java7支持新的編程語言特徵來利用棧空間。比如，引入了continuations模型，編程語言的一個著名概念。Continuations模型對於
協同程序、綠色線程（green thread）、纖程（fiber）非常有用 。當實現非阻塞I/O時，一個大的優勢是，代碼可以根據線程實際使用情況編寫，但是運行時仍然在後台採用非阻塞I/O。Elasticsearch使用了多個線程池，因為Netty I/O框架和Guava是Elasticsearch的基礎組件，因此在用Java7時，可以考慮進一步挖掘優化線程的特性。
發揮增加棧空間大小的優勢還是有挑戰的，因為不同的操作系統、不同的CPU架構，甚至在不同的JVM版本之間，棧空間的消耗不是容易比較的。取決於CPU架構和操作系統，JVM的棧空間大小是內建的。他們是否在所有場景下都適合？例如Sloaris Sparc 64位的JVM Xss默認為512K，因為有更大地址指針，Sloaris X86為320K。Linux降為256K。Windows 32位Java6默認320K，Windows 64位則為1024K。