案例
某数据计算系统，日处理亿级数据量。系统不断从各种数据源提读数据，加载到JVM内存进行计算处理：
该系统不停通过SQL等方式从各数据存储中读数据到内存中进行计算，执行500次/min的数据提取和计算任务。这是套分布式系统，线上部署了多台机器：
每台机器大概负责执行100次/min的数据提取和计算任务
每次读约1w条数据到内存进行计算，平均每次计算约耗10s
每台机器4核8G，JVM内存4G：新生代、老年代分别1.5G
新生代多久会满？
每次1w条数据大概占多大内存呢？这里每条数据都较大，平均每条数据含20个字段，可认为平均每条数据1KB，则每次计算任务的1w条数据就是10MB。
若新生代按8:1:1分配Eden和两块Survivor区域，则Eden=1.2GB，每块Survivor=100MB：
则每次执行一个计算任务，就会在Eden分配10MB对象，约对应100次/min的计算任务。所以新生代里的Eden区，基本上1min左右就满。
Minor GC时，多少对象进入老年代？
假设新生代Eden在1min后满了，然后接着继续执行计算任务时，必然导致需要进行Minor GC，回收一部分垃圾对象。执行Minor GC之前会先进行检查：
第一步，老年代可用内存＞新生代全部对象？
此时老年代空，有1.5G可用内存，新生代Eden大概算做有1.2G对象。
此时，即使一次Minor GC，全部对象都存活，老年代也能放下，则此时就会直接执行Minor GC。
那此时Eden有多少对象存活，无法被GC呢？
每个计算任务1万条数据，需计算10s，假设此时80个计算任务都执行结束，但还有20个计算任务共计200MB数据还在计算，此时就是200MB对象是存活的，不能被GC，然后有1G对象可GC：
此时一次Minor GC就会回收1G对象，然后200M对象能放入Survivor区吗？
**不能！**因为任一块Survivor区实际上就100M空间，此时就会通过空间担保机制，让这200MB对象直接进入老年代，占用里面200MB内存空间，然后Eden区清空：
系统运行多久，老年代大概就会填满？
这系统大概运行多久，老年代会填满？按上述计算，每min都是个轮回，大概就是每min都会把新生代Eden填满，然后触发一次Minor GC，然后大概都会有200MB数据进入老年代。
若2min过去了，此时老年代有400M被占用，只有1.1G可用，若第3分钟运行完毕，又要进行Minor GC，会做什么检查呢？
先检查老年代可用空间 ＞ 新生代全部对象？
此时老年代可用空间1.1GB，新生代对象有1.2GB，此时假设一次Minor GC过后新生代对象全部存活，老年代是放不下的，就得看“-XX:-HandlePromotionFailure”参数，一般都会打开
此时会进入第二步检查
老年代可用空间 ＞ 历次Minor GC过后进入老年代的对象的平均大小
大概每min执行一次Minor GC，每次大概200M对象进入老年代。那此时发现老年代1.1G，大于每次Minor GC后平均的200M。所以本次Minor GC后大概率还是有200MB对象进入老年代，1.1G可用空间足够。所以此时就会放心执行一次Minor GC，然后又是200MB对象进入老年代。
转折点大概在运行了7min后，7次Minor GC后，大概1.4G对象进入老年代，老年代剩余空间就不到100MB ，几乎快满：
系统运行多久，老年代会触发1次Full GC？
大概在第8min运行结束时，新生代又满，执行Minor GC前进行检查，发现老年代只有100M，比200M小，就会直接触发一次Full GC。
Full GC会把老年代的垃圾对象都给回收，假设此时老年代被占据的1.4G全都是可回收对象，则此时一次就会把这些对象都回收：
然后接着就会执行Minor GC，此时Eden区情况，200MB对象再次进入老年代，之前Full GC就是为这些新生代本次Minor GC要进入老年代的对象准备：
基本平均7、8分钟一次Full GC，这频率相当高。因为每次Full GC很慢， 性能很差。
如何JVM调优？
因为这数据计算系统，每次Minor GC的时候，必然会有一批数据没计算完，但按现有内存模型，最大问题是每次Survivor区放不下存活对象。
所以增加新生代内存比例，3GB堆内存，2GB分给新生代， 1GB给老年代。这样Survivor区大概200M，每次刚好能放下Minor GC后存活对象：
只要每次Minor GC过后200MB存活对象可以放Survivor区域，等下次Minor GC时，这个Survivor区的对象对应的计算任务早就结束了，都可以回收。此时比如Eden区1.6G被占满，然后Survivor1有200MB上一轮 Minor GC后存活的对象：
然后此时执行Minor GC，就会把Eden 1.6G对象回收，Survivor1里200MB对象也会回收，然后Eden区剩余200MB存活对象会放入Survivor2区：
以此类推，基本上就很少对象会进入老年代，老年代里的对象也不会太多。
通过这个优化，成功将生产系统的老年代Full GC频率从几min一次降低到几h一次，大幅提升系统性能，避免频繁Full GC对系统性能影响。
一个动态年龄判定升入老年代的规则，若：
S u r v i v o r 区 中 的 同 龄 对 象 ＞ 超 过 S u r v i v o r 区 内 存 / 2 Survivor区中的同龄对象＞超过Survivor区内存/2Survivor区中的同龄对象＞超过Survivor区内存/2
就要直接升入老年代。所以此处优化仅是为说明：增加Survivor区大小，让Minor GC后的对象进入Survivor区中，避免进入老年代。
为避免动态年龄判定规则把Survivor区中的对象直接升入老年代，若新生代内存有限，可调整"- XX:SurvivorRatio=8"参数：默认Eden区比例80%，也可降低Eden区比例，给两块Survivor区更多内存空间，然后让每次Minor GC后的对象进入Survivor区中，还可避免动态年龄判定规则直接把他们送入老年代。
垃圾回收器
在新生代和老年代进行垃圾回收的时候，都是要用垃圾回收器进行回收的，不同的区域用不同的垃圾回收器。
**Serial和Serial Old垃圾回收器：**分别用来回收新生代和老年代的垃圾对象
工作原理就是单线程运行，垃圾回收的时候会停止我们自己写的系统的其他工作线程，让我们系统直接卡死不动，然后让他们垃圾回收，这个现在一般写后台Java系统几乎不用。
**ParNew和CMS垃圾回收器：**ParNew现在一般都是用在新生代的垃圾回收器，CMS是用在老年代的垃圾回收器，他们都是多线程并发的机制，性能更好，现在一般是线上生产系统的标配组合。下周会着重分析这两个垃圾回收器。
**G1垃圾回收器：**统一收集新生代 和老年代，采用了更加优秀的算法和设计机制，是下下周的重点，一周都会来分析G1垃圾回收器的工作原理和优缺点。
