javascript函数执行上下文在函数执行结束时立即由引擎从调用栈弹出并同步销毁，不依赖垃圾回收器；而堆中对象是否回收取决于是否有其他引用，由gc的标记-清除等算法异步处理。
JavaScript 函数执行上下文本身不被垃圾回收器直接回收，而是在函数执行结束时由引擎自动销毁；它和堆内存中的对象回收是两个不同层面的机制。
简单说：
执行上下文（EC）是栈结构管理的运行时环境，生命周期由调用栈控制；
而垃圾回收（GC）只负责堆中对象的内存释放，不处理执行上下文本身。
执行上下文的销毁时机很明确
- 当一个函数执行完毕，它的执行上下文会立即从调用栈中弹出；
- 此时该上下文所关联的变量对象（VO）、作用域链、this 绑定等全部失效；
- 引擎不再保留对该上下文的任何引用，也不再允许访问其中的局部变量；
- 这个过程与 GC 无关，也不依赖 GC 触发，是同步、确定性的行为。
例如：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
function foo() {
let a = { name: 'Alice' };
let b = [1, 2, 3];
}
foo(); // 执行一结束，foo 的执行上下文立刻销毁
→ foo 的上下文此时已不存在；
→ a 和 b 所指向的堆对象是否被回收，取决于它们是否还有其他引用（比如闭包、全局变量、事件监听器等）。
堆对象的回收才靠垃圾回收器
执行上下文销毁后，它内部声明的局部变量如果还被其他地方引用（如闭包），对应堆对象就不会被回收；
如果没有外部引用，这些对象会在下一次 GC 周期中被标记为不可达，然后被清除。
GC 主要采用两种策略：
- 新生代：用 Scavenge 算法，适合短命小对象（如函数内创建的临时对象）；
- 老生代：用 Mark-Sweep 或 Mark-Compact，处理长期存活的大对象。
关键点在于：
✅ 执行上下文销毁 → 局部变量引用消失 → 堆对象可能变“不可达”
✅ GC 后续扫描 → 发现不可达对象 → 回收其占用的堆内存
但注意：
❌ GC 不销毁执行上下文；
❌ 执行上下文销毁也不等于堆对象马上被回收；
❌ 如果有闭包捕获了局部变量，即使函数执行完了，那些对象仍被引用，就不会被 GC。
如何避免因上下文残留导致内存泄漏
- 避免无意中创建长生命周期闭包（比如把函数返回并赋给全局变量，同时它又引用了大对象）；
- 及时解除事件监听、定时器、DOM 引用等外部持有关系；
- 在不需要时手动断开引用，比如
obj = null，帮助 GC 更早识别可回收对象； - 不要滥用
arguments、eval或with，它们会阻碍 V8 的优化和上下文清理。
函数执行上下文的销毁是 JS 引擎运行时的底层保障，你不需要、也无法手动干预；真正需要关注的是堆上对象的引用关系——它决定了 GC 能否顺利回收。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
