堆内存存储对象本体，栈内存存储基本类型和引用变量；堆中对象被多线程共享，栈中变量线程私有；栈溢出因递归过深或局部变量过多，堆溢出因对象过多或过大且GC无法及时回收。
堆内存存对象，栈内存存“谁在用对象”
Java里所有 new 出来的对象（包括数组、String 实例、ArrayList 等）都落在堆中；而方法里定义的 int、boolean、double 这类基本类型，以及像 String s 这种“引用变量”，全在栈上——注意：s 本身是栈里的一个地址值，它指向的字符串内容可能在堆里（new String("abc")）或字符串常量池里（"abc"）。
- 常见错误现象：
StackOverflowError通常是因为递归太深或局部变量太多，栈帧撑爆了；OutOfMemoryError: Java heap space则是堆里对象太多、GC 清不掉，或者单个对象过大（比如加载几百MB文件到 byte[]） - 使用场景：想让多个方法共享数据？必须靠堆里的对象，栈上的变量出作用域就没了；想快速临时存个计数器或布尔开关？栈最省事也最安全
- 性能影响：栈分配只要移动指针，快如闪电；堆分配要查空闲链表、触发 GC、处理碎片，慢且不可预测
栈是线程私有的，堆是所有线程共用的
每个线程启动时，JVM 就给它配好一块独立的栈空间（默认一般 1MB，可用 -Xss 调），所以你在方法里声明 int count = 0，别的线程根本看不见这个 count；但如果你 new HashMap() 并把它传给另一个线程，那大家操作的是堆里同一个对象——这就引出了线程安全问题。
- 容易踩的坑：直接把堆里的
ArrayList当作线程间通信容器，没加锁或没换CopyOnWriteArrayList，大概率出现ConcurrentModificationException或数据错乱 - 参数差异：栈大小由
-Xss控制，改太小会容易StackOverflowError；堆初始/最大值由-Xms/-Xmx控制，设太小会频繁 GC，设太大可能导致 GC 暂停时间过长 - 兼容性影响：高并发服务如果每个请求都新建大量短生命周期对象，堆压力大，GC 频繁；而深度嵌套的 JSON 解析或正则匹配，容易吃光栈空间，尤其在
ThreadLocal存了大对象又没清理时
栈内存自动释放，堆内存靠 GC 回收——但不是“马上”
方法执行完，它对应的栈帧立刻弹出，里面所有局部变量（包括引用）瞬间失效；但堆里的对象不会因为没人引用就立刻消失——GC 只在合适时机扫描、标记、清理，中间可能隔几秒甚至几分钟。这意味着：你 list = null 或让引用超出作用域，只是“允许 GC 回收”，不是“命令 GC 立刻回收”。
- 常见错误现象：反复
new byte[1024*1024]做缓存却忘了及时置为null或用完释放，GC 来不及回收，很快触发OutOfMemoryError - 实操建议：大对象（如图片、文件流）尽量用完即弃，避免长期持有引用；用
try-with-resources确保InputStream类资源释放，这不是释放堆内存，而是防止底层句柄泄漏 -
为什么这样做：GC 是分代的（年轻代、老年代），新对象先在 Eden 区，熬过几次 Minor GC 才进老年代；一次
System.gc()调用也不保证立即执行，纯属建议
别被“String 在常量池”带偏——堆和栈的边界很清晰
String s = "hello" 中，s 是栈上的引用，"hello" 字面量存在方法区（JDK 7+ 后移到堆中的运行时常量池）；而 String s = new String("hello") 会强制在堆中再建一个对象，哪怕内容一样。这说明：栈只管“怎么访问”，堆（或方法区）才管“东西放哪”。
立即学习“Java免费学习笔记（深入）”；
- 容易踩的坑：
==比较两个String，结果是false，因为它们在堆里是不同对象，即使内容相同；该用.equals() - 实操建议：字符串拼接少用
+（尤其循环中），它背后是新建StringBuilder再toString()，每次都在堆里造新对象；高频场景改用StringBuilder复用 - 关键点：常量池位置随 JDK 版本迁移过（JDK 6 在永久代，7 在堆，8+ 在元空间），但栈/堆分工始终没变——栈永远不存对象本体，只存基本类型和引用
