Java 堆区在 JVM 启动的时候即被创建，其空间大小也就确定了。
设置堆内存大小：
-Xms 设置堆的起始内存，等价于-XX:InitialHeapSize-Xmx 设置堆的最大内存，等价于-XX:MaxHeapSize建议：将 -Xms 和 -Xmx 两个参数配置相同的值（避免GC前后堆内存的扩容和释放，减少不必要的性能损耗）
查看堆内存大小：
VM option 添加 -XX:+PrintGCDetails（程序运行结束打印堆空间信息）jstat -gc 进程id（通过jps获取进程id）默认情况下
public class HeapSpaceInitial {
public static void main(String[] args) {
// 运行时数据区内存
long initialMemory = Runtime.getRuntime().totalMemory();
long maxMemory = Runtime.getRuntime().maxMemory();
// JVM堆内存
System.out.println("-Xms : " + initialMemory / 1024 + "K");
System.out.println("-Xmx : " + maxMemory / 1024 + "K");
// 电脑物理内存
System.out.println("系统内存大小：" + initialMemory * 64.0 / 1024 / 1024 / 1024 + "G");
System.out.println("系统内存大小：" + maxMemory * 4.0 / 1024 / 1024 / 1024 + "G");
try {
TimeUnit.MINUTES.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
一旦堆区中的内存大小超过-Xmx所指定的最大内存时，将会抛出 OutOfMemoryError 异常。
public class OOMTest {
public static void main(String[] args) {
ArrayList<Picture> list = new ArrayList<>();
while (true) {
try {
Thread.sleep(20);
} catch (InterruptedException e) {
e.printStackTrace();
}
list.add(new Picture(new Random().nextInt(1024 * 1024)));
}
}
}
class Picture {
private byte[] bytes;
public Picture(int length) {
this.bytes = new byte[length];
}
}
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at heap.Picture.<init>(OOMTest.java:26)
at heap.OOMTest.main(OOMTest.java:16)
Java 堆从 GC 的角度可以细分为：新生代（Eden、Survivor0 、 Survivor1 ）和 老年代。
新生代 和 老年代 在堆结构的占比：
-XX:NewRatio=2，表示新生代占 1，老年代占 2，新生代占整个堆的 1/3，老生代占整个堆的 2/3-XX:NewRatio=4，表示新生代占 1，老年代占 4，新生代占整个堆的 1/5，老生代占整个堆的 4/5在 HotSpot 中，Eden区 和 另外两个 Survivor区的占比：
-xx:SurvivorRatio=8，表示 Eden占8，From占1，To占1，Eden占整个年轻代的 1/10内存分配自适应，实际比例为 6：1：1，可通过 -XX:-UseAddaptiveSizePolicy 关闭。可以使用选项-Xmn设置新生代最大内存大小，这个参数一般使用默认值就可以了。
-XX:NewRatio发生冲突，以-Xmn为准其实不分代完全可以，分代的唯一理由就是优化 GC 性能。
如果没有分代，那所有的对象都在一块，GC 的时候要找到哪些对象没用，这样就会对堆的所有区域进行扫描。
而很多对象其实都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当 GC 的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。
JVM 在进行 GC 时，并非每次都对堆三个内存区域一起回收的，大部分时候回收的都是指新生代。
针对 Hotspot VM 的实现，它里面的 GC 按照回收区域又分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（FullGC）
在发生 Minor GC 之前，JVM 会检查 老年代最大可用的连续空间 是否大于 新生代所有对象的总空间。
老年代最大可用连续空间 是否大于 历次晋升到老年代的对象的平均大小。
触发 Full GC 执行的情况有如下五种：
说明：Full GC 是开发或调优中尽量要避免的。
存储在 JVM 中的 Java对象 可以被划分为两类：
生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速（新生代中 80%的对象都是“朝生夕死”的）生命周期很长的对象，在某些极端的情况下还能够与 JVM 的生命周期保持一致。Java对象的分配过程如下：
new 的对象优先分配到 Eden区。
-XX:PretenureSizeThreshold 设置多大的对象直接进入老年代）当Eden区空间不足时（放不下新new的对象），触发 Minor GC，进行新生代的垃圾回收。
什么时候会将对象放到老年代呢？
当 GC后 Eden区 存活的对象 Survivor区 放不下。（空间分配担保）
当 对象存活年龄 达到阈值时。（默认为15，可以通过 -XX:MaxTenuringThreshold 设置）
Survivor区中，相同年龄的所有对象大小的总和大于 Survivor 空间的一半，年龄 >= 该年龄的对象直接进入老年代。
当老年代空间不足时，触发 Major GC，进行老年代的垃圾回收。
若老年代执行了 Major GC 之后，发现依然无法进行对象的保存，就会产生 OOM 异常。
流程图
TLAB，Thread Local Allocation Buffer，是 JVM 在 Eden区 为 每个线程 分配的一块 私有缓存区域（线程私有）
堆区是线程共享区域，任何线程都可以访问到堆区中的共享数据。
由于对象实例的创建在 JVM 中非常频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的。
TLAB 是 JVM 在 Eden区 为 每个线程 分配的一块 私有缓存区域（线程私有）。多线程同时分配内存时，使用 TLAB 可以避免一系列的
线程安全问题，同时还能够提升内存分配的吞吐量（快速分配策略）
在程序中，开发人员可以通过
-XX:UseTLAB 设置是否开启 TLAB 空间。jps 和 jinfo -flag UseTLAB 进程id 查看是否开启（默认是开启的）默认情况下，TLAB 空间的内存非常小，仅占有整个 Eden 空间的 1%
-XX:TLABWasteTargetPercent 设置 TLAB 空间所占用 Eden 空间的百分比大小。尽管不是所有的对象实例都能够在 TLAB 中成功分配内存，但 JVM 确实是将 TLAB 作为内存分配的首选。
一旦对象在 TLAB 空间分配内存失败，JVM 就会通过加锁等机制确保数据操作的原子性，从而直接在 Eden 空间中分配内存。
堆是分配对象存储的唯一选择吗？
在《深入理解 Java 虚拟机》中关于 Java 堆内存有这样一段描述：随着 JIT 编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换等优化将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。
在JVM中，对象一般都是在 Java 堆中分配内存的，但是，有一种特殊情况，那就是 如果经过逃逸分析（Escape Analysis）后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。
此外，基于 OpenJDK 深度定制的 TaoBaoVM，其中 GCIH（GC invisible heap）技术实现 off-heap，将生命周期较长的 Java 对象从 heap 中移至 heap 外，并且 GC 不能管理 GCIH 内部的 Java 对象，以此达到降低 GC 的回收频率和提升 GC 的回收效率的目的。
但是，Oracle Hotspot JVM 中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确：对于Oracle Hotspot JVM 来说，所有的对象实例都是创建在堆上。
逃逸分析是一种跨函数全局数据流分析算法，可以有效减少 Java 程序中 同步负载 和 内存堆分配压力。
通过逃逸分析，Java Hotspot 编译器能够分析出一个新的对象的引用的使用范围，从而决定是否要将这个对象分配到堆上。
逃逸分析的基本行为就是分析对象的动态作用域：
结论：开发中能使用局部变量的，就不要使用在方法外定义。
【例1】
public void my_method() {
V v = new V();
// use v
// ....
v = null;
}
对象V只在方法内部使用，没有发生逃逸，则可以分配到栈上，随着方法执行的结束，栈空间就被释放。
【例2】
public static StringBuffer createStringBuffer(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb;
}
上述代码中，StringBuffer sb对象被作为方法的返回值返回出去，可能被外部方法所引用，发生了逃逸。
如果想要StringBuffer sb不发生逃逸，可以这样写
public static String createStringBuffer(String s1, String s2) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb.toString();
}
【例3】
如何快速判断是否发生逃逸？就看new的对象实体是否有可能在方法外被使用
public class EscapeAnalysis {
public EscapeAnalysis obj;
/**
* 方法返回EscapeAnalysis对象，发生逃逸
*/
public EscapeAnalysis getInstance() {
return obj == null ? new EscapeAnalysis() : obj;
}
/**
* 为成员属性赋值，发生逃逸（如果obj引用被声明为静态的？仍然会发生逃逸）
*/
public void setObj() {
this.obj = new EscapeAnalysis();
}
/**
* 对象的作用于仅在当前方法中有效，没有发生逃逸
*/
public void useEscapeAnalysis() {
EscapeAnalysis e = new EscapeAnalysis();
}
/**
* 引用成员变量的值，发生逃逸（这个属于getInstance()创建的对象逃逸到当前方法）
*/
public void useEscapeAnalysis2() {
EscapeAnalysis e = getInstance();
}
}
在 JDK 6u23 版本之后，HotSpot 中默认就已经开启了逃逸分析
如果使用的是较早的版本，开发人员则可以通过：
-XX:+DoEscapeAnalysis：显式开启逃逸分析-XX:+PrintEscapeAnalysis：查看逃逸分析的筛选结果-server：启动 Server 模式，因为在 server 模式下，才可以启用逃逸分析。如果本身就是Server模式，可以省略-server
使用逃逸分析，编译器可以对代码做如下优化：
JIT 编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。
分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须进行垃圾回收了。
/**
* -Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
*/
public class StackAllocation {
public static void main(String[] args) {
long start = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
alloc();
}
// 查看执行时间
long end = System.currentTimeMillis();
System.out.println("花费的时间为： " + (end - start) + " ms");
// 为了方便查看堆内存中对象个数，线程sleep
try {
Thread.sleep(1000000);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
private static void alloc() {
User user = new User(); // 未发生逃逸
}
static class User {
}
}
通过 -XX:-DoEscapeAnalysis 关闭逃逸分析 和 -XX:+DoEscapeAnalysis 开启逃逸分析 对比两次的结果
-Xmx128m -Xms128m -XX:+PrintGCDetails：堆内存设小一点，看是否发生GC（栈上分配不会发生GC）-Xmx1g -Xms1g：堆内存设大一点，在不GC的情况下，通过jvisualvm查看对象个数下图可以看到，没有开启逃逸分析时，堆内存中有10000000个User对象
动态编译同步块时，JIT 编译器可以借助逃逸分析，判断
synchronized锁对象是不是只可能被一个线程加锁，不存在其他线程来竞争加锁的情况。如果是，JIT 编译器在编译的时候就会取消对这部分代码的同步，这个过程就叫同步省略，也叫锁消除。
- 参数
-XX:+EliminateLocks：开启同步替换（默认打开）。
线程同步的代价是相当高的，同步的后果是降低并发性和性能。同步省略可以大大提高并发性和性能。
public void syncTest() {
Object obj = new Object();
synchronized(obj) {
System.out.println(obj);
}
}
上述代码中，对 obj 对象加锁，但是obj 对象的生命周期只在方法内，不会逃逸，所以在 JIT 编译阶段就会把锁优化掉，如下所示：
public void syncTest() {
Object obj = new Object();
System.out.println(obj);
}
需要注意的是，上述是字节码文件加载到内存中以后的优化，直接反编译字节码文件可以看到，synchronized还是存在的。
如果有的对象不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在堆中，而是存储栈中
在 JIT 阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过 JIT 优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。
标量替换-相关概念
标量（scalar）是指一个无法再分解成更小的数据的数据。Java 中的基本数据类型就是标量。
聚合量（Aggregate）是指那些还可以分解的数据。Java 中的对象就是聚合量，因为他可以分解成其他聚合量和标量。
标量替换-参数设置
-XX:EliminateAllocations：开启了标量替换（默认打开），允许将对象打散分配到栈上。/**
* -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations
*/
public class ScalarReplaceTest {
public static void main(String args[]) {
long start = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
alloc();
}
long end = System.currentTimeMillis();
System.out.println("花费的时间为： " + (end - start) + " ms");
}
private static void alloc() {
Point point = new Point(1, 2); // 未发生逃逸
System.out.println("point.x" + point.x + ";point.y" + point.y);
}
public static class Point {
private int x;
private int y;
public Point(int x, int y) {
this.x = x;
this.y = y;
}
}
}
以上代码，经过标量替换后，就会变成
private static void alloc() {
int x = 1;
int y = 2;
System.out.println("point.x = " + x + "; point.y=" + y);
}
可以看到，Point 这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个标量了。那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。 标量替换为栈上分配提供了很好的基础。
关于逃逸分析的论文在 1999 年就已经发表了，但直到 JDK1.6 才有实现，而且这项技术到如今也并不是十分成熟。
根本原因就是：无法保证逃逸分析带来的优化一定高于逃逸分析的性能消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。
一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。
通过逃逸分析，JVM 会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于 JVM 设计者的选择。Oracle Hotspot JVM 中似乎并未这么做，这一点在逃逸分析相关的文档里已经说明，所以对于 Oracle Hotspot JVM ，所有的对象实例都是创建在堆上。
因篇幅问题不能全部显示，请点此查看更多更全内容