延迟式垃圾回收机制的缺陷

因为疫情关系，需要远程办公，原先封闭的内网开放了外传端口，写文章又有素材了。当然不是直接的工作内容，而是相关的体验、笔记可以趁空整理发表

概述

大内存下不释放，堆积了大量小内存(比如对象)，一旦访问就卡程序。

---

按时间分类的自动垃圾回收机制

与显式调用 malloc()、free()不同，自动垃圾回收机制就是编程语言自动管理了内存的分配和释放，可以归结为两大类

1. 实时释放: COM 对象通过引用计数实现，引用计数归零立即释放。COM 的代表语言就是 VB6。优缺点是
   1. 用完就释放，不存在占坑的垃圾。
   2. 没有整理，容易产生内存小碎块。在G级内存下普通前台程序基本不会有内存不足的问题。
   3. 循环引用导致的内存泄漏。典型就是树节点的父子互相引用，只要从根节点开始深度遍历进行节点拆分，就能解决。
2. 延时释放：不管采用何种策略，总是先扔在那里不管，到必要时(内存用量超过某个警戒线)，开始批量释放。代表语言 java、VB.NET、C#等。优缺点是
   1. 节省操作、提高性能。靠省CPU操作提高的性能，抵不过芯片的升级换代。
   2. 容易卡顿。无论是操作一小部分还是全体，总需要先暂停程序，然后内核去查找、标记：有用/无用，至于接下来是把有用的整理出来保留还是把无用的释放就是策略问题了。表现就是 java 程序内存耗用上去后就常卡。
   3. 大内存下表现不佳。因为无需释放，垃圾回收器中的对象数量是恐怖的，这就是接下来要讨论的。

---

案例

Windows 下用 Eclipse 编写的 java 中间业务层，前台 jsp 页面，后台数据库。

整个项目 .java 文件 1800+，代码行 1100万，Eclipse 刚启动、准备调试时耗内存 400M+。数据库的几个明细表记录也在千万级。

缺陷

在 4G 内存的时候，经常卡，归结为内存不足。

换成 16G 内存，发现 1G< 耗用内存 < 2G 的时候，程序运行还没问题，如果要加个断点，就会卡。

分析加猜测

这时新增内存耗用大概 1G，而数据库很少有大文本，java 对象大概就是几十字节大小。也就是说垃圾回收器中的对象数量已经达到千万级了。而加断点不知为何需要遍历这么多对象(观察任务管理器内存没降，也就是没有 System.gc 强制回收）。

 2G/16G 当然没有达到必须回收的标准，对象数量千万甚至上亿对调试太不友好了，加减断点、更改断点状态都会卡分钟级了。

由于Web服务运行的时间是月、年等级的，，总会有累计到“需要”释放的时候，而且真实环境内存更多，那时对象数量就是上亿级了，不知道会卡多久。

也许

也许延时释放又要加个判断机制，对象数超过某个警戒线就触发释放。如果本次释放没有释放掉多少对象，就把警戒线提上去，以适应当前程序的常驻对象数。

题外话

微软抛弃的 COM 转投延时释放，不知道 VB.NET、C# 有没有碰到类似情况。

CSDN 的 MarkDown 格式编辑怎么没有标签、分类的输入项？