---
title: "动态清零？ 这不就是GC吗"
description: "GC(垃圾回收)的原因是：总会有垃圾出现需要回收，释放内存。动态清零的原因是：总有感染者出现，需要控制。目前"
date: 2022-05-09T10:56:47Z
canonical: https://xiaobox.github.io/p/2022-05-09-dong-tai-qing-ling-zhe-bu-jiu-shi-gc-ma/
author: 小盒子
categories: ["后端"]
tags: ["JVM", "Kubernetes", "Docker", "算法", "多线程"]
source: https://mp.weixin.qq.com/s/x-Mbthxm07Gqn0Hix62MYQ
license: CC BY-NC-SA 4.0
license_url: https://creativecommons.org/licenses/by-nc-sa/4.0/
---

# 动态清零？ 这不就是GC吗

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，祝所有“容器化”的朋友们好运，宿主机会好的，等待你们重启的那一天。祝所有人平安、健康。