GC(垃圾回收)的原因是：总会有垃圾出现需要回收，释放内存。
动态清零的原因是：总有感染者出现，需要控制。
目前看来，动态清零用的方法是 Mark-Sweep，即标记（核酸）-清理（方舱）
类比垃圾回收器有点儿像 CMS，但由于内部网格化管理 实际上更像G1 这种分区回收的垃圾回收器，比如上海。
我们都知道无论是CMS还是G1都会有STW（stop the world），垃圾回收器们一般都是在高吞吐和低延迟之间做权衡。没有最好，只有最合适。
然而动态清零看起来却不是，这是个区别，它有着明显的停顿（STW），又有着比较低的吞吐。希望能够在算法上进行优化，我们的特点是内存大（人口基数大），是不是可以借鉴ZGC，ZGC 和 G1 一样是基于 reigon 的，几乎所有阶段都是并发的，整堆扫描，部分收集。它的停顿时间也明显优于G1和CMS。
目前来看北京的模式有点儿像ZGC 的特点，整堆扫描（核酸），部分收集（封控）。
另外从隔离性上讲，上海类似 docker，把自己整体容器化，资源隔离了，北京类似K8S的 Pod，对外还能保证可用性，只不过部分Pod 可能会出现问题，那就解决Pod的问题就好了。只要不全挂 ，因为没有冗余设备（也不可能有）。
看来动态清零是一个长期的事儿了，就像GC虽然程序员不需要时刻注意垃圾回收的问题，但它一直在后台默默运行着，帮我们解决着内存回收的问题。希望动态清零也能够优化到“静默”运行，在高吞吐和低延迟间做好 trade off。
我们能够接受和它长期并存，现实世界不是程序，希望它能够少些 STW，祝所有“容器化”的朋友们好运，宿主机会好的，等待你们重启的那一天。祝所有人平安、健康。