Java堆存对象和数组等线程共享数据，栈存线程私有的局部变量、参数等；对象总在堆里因栈仅存引用，实际数据需垃圾回收与线程隔离支持。
Java堆和栈到底存什么，为什么对象总在堆里
Java程序运行时的内存划分不是凭空设计的，而是为了配合垃圾回收和线程隔离。堆（Heap）是所有线程共享的区域，你用 new 创建的对象、数组，全在这里分配；栈（Java Virtual Machine Stacks）则是每个线程私有的，只存局部变量、方法参数、返回地址这些生命周期明确的小东西。
常见错误现象：把大对象（比如几十MB的字节数组）反复在方法里声明，栈不会崩，但堆会快速撑满——因为栈只存引用，实际数据还在堆上。
- 基本类型变量（
int、boolean）在栈里存值；引用类型变量（如String、ArrayList）在栈里存地址，对象本体一定在堆里 - 逃逸分析可能让某些对象“栈上分配”，但这只是JVM优化，开发者不能直接控制，也不该依赖
- 栈空间默认较小（一般1MB左右），递归过深或局部变量过多会触发
StackOverflowError；堆空间默认较大（如G1默认初始4MB，可动态扩展），但溢出报的是OutOfMemoryError: Java heap space
JVM方法区去哪儿了：从永久代到元空间的变化
方法区存放类信息、常量、静态变量、即时编译后的代码。它不等同于“永久代（PermGen）”，后者只是JDK 7及之前HotSpot对方法区的一种实现；JDK 8起彻底移除了永久代，改用本地内存实现的元空间（Metaspace）。
使用场景：动态生成类（如Spring CGLIB代理、Groovy脚本热加载）容易撑爆方法区。以前调 -XX:MaxPermSize，现在得调 -XX:MaxMetaspaceSize。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 字符串常量池在JDK 7后从永久代移到了堆中，所以
String.intern()的行为变了：重复字符串不再导致永久代OOM，但可能加重堆压力 - 元空间使用本地内存，理论上只受系统限制，但没设
-XX:MaxMetaspaceSize时仍可能因类加载器泄漏（如Web应用热部署未清理）导致本地内存耗尽 -
java.lang.OutOfMemoryError: Metaspace出现时，优先检查是否频繁定义新类，而不是盲目加大参数
直接内存不是JVM内存，但Java程序一样会用到
直接内存（Direct Memory）不在JVM规范定义的运行时数据区里，它由操作系统管理，但Java通过 java.nio.ByteBuffer.allocateDirect() 可以申请。典型用于NIO读写、Netty零拷贝等高性能场景。
容易踩的坑：直接内存不受 -Xmx 控制，但总量受 -XX:MaxDirectMemorySize 限制（默认等于 -Xmx）。忘了设这个值，又大量用 allocateDirect，就会触发 OutOfMemoryError: Direct buffer memory。
- 直接内存的GC不走常规堆回收流程，依赖
Cleaner机制，在Full GC时才尝试释放——这意味着它可能比堆对象更晚被回收 - 用
ByteBuffer.wrap(byte[])是堆内缓冲区，allocateDirect()才是真正的直接内存；别以为用了NIO就自动走直接内存 - 监控工具如JConsole、VisualVM默认不显示直接内存用量，需看
java.lang:type=MemoryPool,name=Code Cache之外的java.lang:type=MemoryPool,name=Metaspace和java.lang:type=MemoryPool,name=Compressed Class Space并不包含它，得查java.lang:type=MemoryPool,name=Direct Buffer Pool（如果支持）或用jstat -gc看CCST和YGC之外的DC（Direct Count）字段
线程本地变量（ThreadLocal）的内存归属容易误判
ThreadLocal 变量本身是堆上的对象，但它持有的值（ThreadLocalMap 中的 Entry）是绑定在线程栈所关联的本地存储里的。关键点在于：这些值的生命周期取决于线程，而不是声明它的类或方法。
常见错误现象：Web容器中用 ThreadLocal 存用户上下文，但没在Filter或拦截器末尾调用 remove()，导致线程复用（如Tomcat线程池）时旧数据残留，甚至引发内存泄漏——因为 ThreadLocalMap 的 Entry 是弱引用Key，但Value是强引用，不手动清理就会一直挂着。
-
ThreadLocal不是“线程私有堆”，它只是提供了一种访问线程关联数据的机制，底层仍是堆对象 + 线程对象内的引用链 - 每次
set()都会往当前线程的ThreadLocalMap里塞一个Entry，Key是当前ThreadLocal实例（弱引用），Value是你传进去的对象（强引用） - 在可能线程复用的环境（如Servlet容器、RPC线程池）中，必须配对使用
set()和remove()，不能只靠initialValue()或get()自动初始化来掩盖泄漏
OutOfMemoryError 报出来时，你能一眼看出它属于哪个区域、对应哪种使用模式——这需要结合日志、参数、代码上下文一起判断，而不是背概念。 
