引用类型内存分配本质是栈存指针、堆存实体：栈中仅存4/8字节地址，指向堆中new出的对象；方法结束栈帧弹出，但堆对象是否回收取决于是否还有其他引用可达。
引用类型在运行时的内存分配，本质是堆与栈协同工作的结果：栈存“指针”，堆存“实体”，二者缺一不可。
栈上只存引用，不存对象本身
声明一个引用类型变量（如 String s 或 ArrayList list），编译器只在当前线程栈中分配一小块空间，用于存放指向堆中实际对象的地址。这个地址就像一张“地图坐标”，本身很小（通常4或8字节），但能定位到堆里任意大小的对象。
- 即使对象很大（比如含百万元素的 List），栈上也只存一个指针，开销恒定
- 方法调用结束后，栈帧弹出，指针消失；但堆中对象是否回收，取决于是否有其他引用指向它
- 多个变量可指向同一堆地址（如
list1 = list2），修改内容会影响所有引用
堆上承载真实数据，生命周期由GC管理
所有通过 new 创建的实例（包括数组、集合、自定义类对象）都落在堆中。堆是线程共享的动态内存区，由垃圾回收器统一追踪和清理。
- 对象字段中的值类型（如
class Person { int age; String name; }）——age和name的引用都随对象一起存在堆上 - 字符串常量池、类元数据（Class、Method）等也驻留在堆的特定区域（如Java的Metaspace）
- GC不会立即释放内存，而是当对象“不可达”（无任何栈/静态引用指向）时，在合适时机回收
嵌套结构下的分配逻辑很清晰
引用类型内部包含值类型，或值类型内部包含引用类型，分配位置依然遵循“归属主体”原则：
- 值类型作为引用类型的字段（如
Point p在class Car { Point location; }中）——p随Car实例一起分配在堆上 - 引用类型作为值类型的字段（如
string name在struct Student中）——name的引用存于栈（若Student在栈），但其指向的字符串对象仍在堆上 - 局部变量是引用类型，但被闭包捕获或逃逸（如返回其地址）——编译器可能将其提升至堆，避免栈销毁后悬空
理解配合关系才能避开典型陷阱
很多性能或逻辑问题，根源在于混淆了栈与堆的职责边界：
- 误判生命周期：以为局部引用变量一出作用域，对象就消失——其实只要还有其他引用（如全局Map缓存），对象仍在堆存活
-
忽视拷贝成本：对大对象频繁赋值（
obj1 = obj2）只是复制指针，极快；但若误以为是深拷贝，后续修改会相互干扰 -
忽略逃逸影响：Go或JVM会分析变量是否逃逸，决定分配在栈还是堆——过度使用
new或返回局部对象地址，会强制堆分配，增加GC压力
