JVM的堆内存实现为什么采用分代思想？
每次被小伙伴问到这种空洞的问题，简直头皮发麻，每次的草草解释，感觉都是苍白无力的语言，词穷的我只能和他们说，算法是慢慢优化，并演化过来的...
先来点专业的知识：1960年，McCarthy和Collins发表了第一篇有关自动动态内存管理（垃圾回收）的论文，而垃圾回收机制最早诞生于1958年的Lisp古老语言。垃圾回收的出现，给软件开发带来的众多收益，大大消除了开发过程中的几大类错误，比如尝试对悬挂指针进行解引用，对已经释放的内存进行二次释放等。
如果没有采用分代思想实现内存，会怎么样？
首先应该知道，新创建的对象都在堆上分配内存，每次垃圾回收，先标记出那些存活的对象（或者是垃圾对象），这时可以采取多种方式进行后续处理。
1、清空垃圾对象，保留存活对象。
这种方式，不会涉及对象复制，应该效率还不错，但是存在致命的问题，可能发生GC几次之后，就出现大量的内存碎片，而这些碎片已经小到不足以分配任何对象。
2、移动存活对象。
这种方式，需要把这些对象移动到内存的一端，可以完美解决内存碎片问题，但是，对于长期活跃的对象，每次GC都要进行移动，特别是对于大对象来说，这个效率实在可怕。
有一个"弱分代假说"，weak generational hypothesis，大概含义是：大多数对象都在年轻的时候死亡，而且这个假说已经在各种不同类型的编程语言中得到证实。因此可以利用这一特性，尽量的提高回收效益（回收之后所得的空间），同时减小回收时的时间开销，这里就需要对第二种方式进行适当的改进，对于一些长期活跃的对象，甚至大对象来说，应该尽量的减少他们被复制的次数，其实就是避免每次垃圾回收都进行复制。
所以，这里很巧妙的引入了分代思想，把整个内存堆分成两块区域，即新生代和老年代。
上图就是HotSpot虚拟机的具体算法实现了，对新生代进行了更细的划分，分成Eden区和2个Survivor，新创建的小对象直接在Eden进行分配，大对象可以选择在老年代进行分配（这样可以有效的防止在YGC的时候进行移动）。
当Eden分配满了之后，就会触发我们熟悉的YGC进行垃圾回收，先标记存活对象，再复制到其中一个Survivor区，如果Survivor区装不下存活对象，那说明JVM参数设置的不太合理，因为Eden区和2个Survivor的默认比例是8:1:1，但是我看到过，有同学竟然在线上环境设置了22:1:1，这个比例实在有点偏激，因为Survivor装不下的对象，会被提前放入老年，会导致老年代提早被用完。
使用这种方式，如果一个对象经历了多次YGC（默认是15次，但是这个值是动态变化的），依然还是存活的，我们就可以粗暴的认为这个对象已经不再年轻，可以进入老年代进行养老了，在之后的YGC，这些对象就不会再参与复制了，有效的避免了上面提到的问题。
其实采用了分代之后，会引入另外一个问题，因为YGC算法只对新生代进行垃圾回收，但是老年代也有被用完的时候，也需要一个对应的垃圾回收算法，很明显，整体的算法复杂度上升了不止一点点，而且为了能够找出新生代全部的存活对象，还需要维护对象之间的跨代的引用，不过相对于分代回收所带来的收益相比，这一开销是值得的。
如何设计分代垃圾回收器，同时达到高吞吐量和低耗时，是一门长期而又精妙的艺术。
欢迎工作一到五年的Java工程师朋友们加入Java架构开发：744677563
本群提供免费的学习指导 架构资料 以及免费的解答
不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导