-Xms768m -Xmx1280m jvm堆的最小值和最大值設置，一般設成相同值，避免頻繁分配堆空間
-XX:NewSize=128m -XX:MaxNewSize=128m 年輕代最小值和最大值設置（年輕代設定了，年老代也就定了），也可以用參數-XX:NewRatio=4，年老代和年輕代的大小比，這裏128m有點小了，官方建議的是heap的3/8，差不多280m
-XX:PermSize=96m -XX:MaxPermSize=128m 持久代最小值和最大值設置
-XX:MaxTenuringThreshold=0 經過多少次minor gc 後進入年老代,設置爲0的話直接進入年老代，這是不太合理的，正常應該在年輕代多呆一段時間，真正需要到年老代的才轉過去
-XX:SurvivorRatio=20000 年輕代中eden和一塊suvivor區的空間比例，這裏設置成20000有問題，suvivor區空間幾乎爲0，一次minor gc後基本都轉到年老代了，年輕代沒有起到過濾左右
-XX:+UseParNewGC 年輕代採用並行gc策略，JDK5.0以上,JVM會根據系統配置自行設置,所以無需再設置此值。使用多線程收集，提高吞吐量（-XX:ParallelGCThreads 並行收集器的線程數，此值最好配置與處理器數目相等，如果超過當前cpu數，會加大機器負載）
-XX:+UseConcMarkSweepGC 年老代採用併發gc策略，和應用程序併發執行，減少pause time，但是需要更大的堆區，因爲併發執行，有碎片（-XX:+UseParallelOldGC 年老代垃圾收集方式爲並行收集，這個是JAVA 6出現的參數選項）
-XX:+CMSPermGenSweepingEnabled 爲了避免Perm區滿引起的full gc，建議開啓CMS回收Perm區選項
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 打印gc日誌
-XX:CMSInitiatingOccupancyFraction=1 年老代使用空間比達到這個值時開始cms gc,默認是在年老代佔滿68%的時候開始進行CMS收集，這裏設置成1是不合理的，會導致CMS GC頻繁發生，從gc日誌裏可以看出來，CMS GC和minor GC幾乎一樣多
-XX:+CMSIncrementalMode 啓動i-CMS模式，增量模式，將cms gc過程分成6個階段，其中階段initial Mark和remark時需要pause，這6個階段在兩次minor gc的間隔期執行，具體執行起止時間由下面兩個參數決定。拆分成小階段增量執行時，可以避免應用被中斷時間過長，極端情況是如果只有一個cpu，那麼得等全部做完這6個階段才能釋放cpu，如果是多cpu這個模式開啓與否應該影響不大。
-XX:CMSIncrementalDutyCycleMin=10 默認值10 啓動CMS的下線
-XX:CMSIncrementalDutyCycle=30 默認值50 啓動CMS的上線
-XX:+UseCMSCompactAtFullCollection 在FULL GC的時候， 對年老代的壓縮。CMS是不會移動內存的， 因此這個非常容易產生碎片， 導致內存不夠用， 因此， 內存的壓縮這個時候就會被啓用。 可能會影響性能,但是可以消除碎片，增加這個參數是個好習慣。
-XX:CMSFullGCsBeforeCompaction=0 上面配置開啓的情況下,這裏設置多少次Full GC後,對年老代進行壓縮，這裏設置成0不知道什麼意思，可以根據線上full gc 的頻率確定，頻率高，這個值可以大點，比如5，反之頻率低，這個值可以小點，比如1
-XX:CMSMarkStackSize=8M
-XX:CMSMarkStackSizeMax=32M