1、JVM内存结构
所以通过表格的形式概括如下：
注：方法区，位于堆的持久代中。但1.8以后，移除持久代，方法区放到堆中，作为元空间。
2、堆内存结构
JVM参数
-Xmx： 表示java虚拟机堆区内存可被分配的最大上限，通常为操作系统可用内存的1/4大小。开发过程中，通常会将 -Xms 与 -Xmx两个参数的配置相同的值，其目的是为了能够在java垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源。
新生代：
大部分对象迅速死亡，存活对象少，因而采用“标记-清除-复制”算法。分为eden区，s0,、s1区。
新生对象大部分分配在eden区，当eden区无法再继续分配新对象时（不一定eden区满），触发Minor GC，将消亡的对象清理掉（作用于 E 区、S0区及 S1 区），并将剩余的对象复制到 S0 区，此时 S1 区是空的。下一次eden区无法再继续分配新对象时，，触发Minor GC，并将剩余的对象复制到S1区，此时S0区是空的。也就是说S0和S1总有一个保持为空。
当新生代对象经历几次MinorGC后（HotSpot 默认为 15 次，可通过-XX:MaxTenuringThreshold控制），会晋升至老年代。
新生代对象分配机制：
jvm参数：
-xmn用于设置年轻代的大小(等同-XX:newSize = -XX:MaxnewSize = -Xmn )，建议设为整个堆大小的1/3或者1/4,两个值设为一样大。
-XX:SurvivorRatio 用于设置Eden和其中一个Survivor的比值，一般E区和S0、S1区比值是8:1:1。
.-XX:InitialTenuringThreshol和-XX:MaxTenuringThreshold
用于设置晋升到老年代的对象年龄的最小值和最大值，每个对象在坚持过一次Minor GC之后，年龄就加1。
-XX:+UseTLAB 默认启用
-XX:TLABWasteTargetPercent：TLAB占eden区的百分比,默认1%
老年代：
老年代采用“标记-清除-整理”算法。
老年代GC为MajorGC，一般MajorGC都会伴随MinorGC（因为对象一般都从新生代晋升老年代，导致老年代空间不足，触发MajorGC。但非绝对的，在 ParallelScavenge 收集器的收集策略里
就有直接进行 Major GC 的策略选择过程）。FullGC为一次majorGC和MinorGC。
永久代：
存放常量池和方法区数据。
JVM参数:
-XX:PermSize和-XX:MaxPermSize来指定最小值和最大值
3、内存分配与回收策略
(1)、对象优先在Eden分区：
大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间分配时，虚拟机发起一次Minor GC。GC后对象尝试放入Survivor空间，如果Survivor空间无法放入对象时，只能通过空间分配担保机制提前转移到老年代。
(2)、大对象直接进入老年代：
大对象指需要大量连续内存空间的Java对象。虚拟机提供-XX:PretenureSizeThreshold参数，如果大于这个设置值对象则直接分配在老年代。这样可以避免新生代中的Eden区及两个Survivor区发生大量内存复制。
(3)、长期存活的对象进入老年代：
虚拟机会给每个对象定义一个对象年龄计数器。如果对象在Eden出生并且经过一次Minor GC后任然存活，且能够被Survivor容纳，将被移动到Survivor空间中，并且对象年龄设为1.每次Minor GC后对象任然存活在Survivor区中，年龄就加一，当年龄到达-XX:MaxTenuringThreshold参数设定的值时，将会移动到老年代。
(4)、动态年龄判断：
虚拟机不是永远要求对象的年龄必须达到-XX:MaxTenuringThreshold设定的值才会将对象移动到老年代去。如果Survivor中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代。
(5)、空间分配担保：
在Minor GC前，虚拟机会检查老年代最大可用连续空间是否大于新生代所有对象总空间，如果条件成立，那么Minor GC是成立的。如果不成立，虚拟机查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用连续空间是否大于历次移动到老年代对象的平均大小，如果大于，将尝试一次Minor GC。如果小于，或者HandlePromotionFailure设置值不允许冒险，那将进行一次Full GC。
minorgc时，会去检查老年代对象引用新生代对象的引用。老年代提供一个专门区域，存放这些信息，提高minorgc检查效率。
4、触发FullGC的条件：
老年代空间不足、
永久代空间不足、
GC担保失败、
CMS的Cocurrent mode failure(发生在cms的清理sweep阶段,发现有新的垃圾产生,而且老年代没有足够空间导致的)
5、对象的创建过程和内存分配
指针碰撞（Bump the Pointer）：假设Java堆中内存是绝对规整的，所有用过的内存都放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，那分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。
空闲列表（Free List）：如果Java堆中的内存并不是规整的，已使用的内存和空闲的内存相互交错，那么虚拟机维护一个列表，并更新列表山的记录。
分配内存过程中还需要解决线程安全问题。 一个修改指针操作，就会带来隐患：对象 A 正分配内存呢，指针还没来得急修改，突然对象 B 又同时使用了原来的指针来分配 B 的内存。解决方案也有两种：同步处理——实际上虚拟机采用 CAS 配上失败重试来保证更新操作的原子性。把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在 Java 堆中预先分配一小块内存，成为本地线程分配缓存（Thread Local Allocation Buffer，TLAB）。哪个线程要分配内存，就在哪个线程的 TLAB 上分配，用完并分配新的TLAB时，才需要同步锁定。
注：由于finalize方法只会被JVM调用一次。
public class FinalizerTest {
public static FinalizerTest object;
public void isAlive() {
System.out.println("I'm alive");
}
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("method finalize is running");
object = this;
}
public static void main(String[] args) throws Exception {
object = new FinalizerTest();
// 第一次执行，finalize方法会自救
object = null;
System.gc();
Thread.sleep(500);
if (object != null) {
object.isAlive();
} else {
System.out.println("I'm dead");
}
// 第二次执行，finalize方法已经执行过
object = null;
System.gc();
Thread.sleep(500);
if (object != null) {
object.isAlive();
} else {
System.out.println("I'm dead");
}
}
}
执行结果：
method finalize is running
I'm alive
I'm dead
方法区的回收主要包括两部分内容：废弃常量和无用的类。
废弃常量的回收与回收Java堆中的对象类似。
判断无用的类的条件必须满足三个条件：
该类所有实例已经被回收。
加载该类的ClassLoader已被回收。
该类对应的java.lang.Class对象没有在任何地方被引用，也无法通过反射访问该类。
谢谢以下分享
网友评论