JavaScript内存抖动的根源是高频创建短生命周期对象导致新生代Scavenge回收过于频繁，而非销毁本身；典型场景包括requestAnimationFrame中反复new对象、列表滚动时为每个item实例化配置对象等。
JavaScript 对象被频繁销毁本身不会直接“导致”内存抖动，真正引发抖动的是高频创建 + 短生命周期 + 集中释放这一组合——它让大量对象在新生代快速堆积又迅速变成垃圾，触发 V8 的 Scavenge 回收过于频繁，造成卡顿和帧率波动。
为什么短命对象集中进出新生代会抖动
新生代内存小、回收快（Scavenge 算法），但前提是“每次只处理少量存活对象”。一旦每秒创建成百上千个临时对象（比如动画帧里 new Vector2、循环中构造 {x, y}），它们立刻填满 From 空间，V8 就不得不频繁执行复制回收：
- 每次 Scavenge 都要扫描所有对象、复制存活者、交换 From/To 空间——虽单次毫秒级，但每秒触发十几次，累积 STW 时间就明显可感
- 若部分对象因闭包、事件监听等意外逃逸到老生代，还会污染老代，后续 Mark-Sweep 耗时更长、停顿更久
- 频繁分配还加剧内存碎片，降低后续大对象分配效率
典型抖动场景长这样
不是“销毁多”，而是“创建得又快又碎、用完就丢”：
- requestAnimationFrame 里反复 new Date()、new Array(3)、Object.assign({}, data)
- 列表滚动时为每个 item 实例化独立配置对象，渲染完即弃
- Canvas 动画中每帧生成新 Path2D、新 ImageData 视图
- 事件回调里临时构造 Promise resolve/reject 参数对象
销毁只是表象，根源在分配节奏失控
JavaScript 没有显式 delete 或 free，所谓“销毁”其实是 GC 发现对象不可达后回收。抖动的关键信号是：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- Chrome DevTools Memory 面板看到 Allocation instrumentation on timeline 中出现密集的蓝色小条（新分配）紧跟着灰色回收块
- Performance 面板中频繁出现 GC Event，且集中在动画或交互密集时段
- 使用 --trace-gc 启动 Node.js 时日志里 GC 日志刷屏
不解决分配，光管销毁没用
试图用 try/finally 或手动置 null 来“加速销毁”基本无效——GC 不靠你删引用，而靠是否还有活跃路径可达。真正有效的是：
- 复用已有对象（如预分配 pointPool.acquire() 替代 {x, y}）
- 把临时计算移到函数外，用局部变量承接（避免闭包捕获）
- 用 TypedArray 或 ArrayBuffer 复用内存块，而非反复 new Uint8Array
- 对结构固定的小对象，改用 Object.freeze 配合池化，防止意外修改状态
抖动不是对象死得多，而是活得太短、来得太密。盯住分配源头，比盯着销毁动作更有价值。
