是不是 gc 过程都会导致应用暂停

JDK 16 中的 ZGC：平均暂停时间 0.05 毫秒 - Glavo 的文章 - 知乎
https://zhuanlan.zhihu.com/p/359249269

0.05 毫秒能满足你的要求吗

@dqzcwxb 所以升级到 JDK16 或 17 可以免费获取很多性能，奈何市面上还是一手 JDK8 打天下。

@12101111 #17 原子引用计数单个确实不高，但是明显你忽略了引用计数需要的操作数可是远远超过了 GC 的，引用计数只是不会导致全局暂停延时而已，并不能降低整体延时，甚至是增加延时的

”进程”会暂时呆住，但是”应用”不一定。这俩并不是同一个概念
其实 Tracing GC 影响的事所有和进行 GC 的堆相关的对象，你在一个进程里放多个 GC 堆隔离起来，也能避免进程暂停

RAII 也有类似的问题，简单粗暴的 RAII 如果出现一个对象拖着一大坨对象，出作用域的时候有得你回收的

gc 是有不同的算法的，常见的有 Reference Counting ，Mark Sweep ，Copy Collection 等等，你可以参考这个文章 https://zhuanlan.zhihu.com/p/54111851 ，了解大概

不一定，现代的一些 GC 实现可以并发回收，暂停个别线程而不是整个进程。实用上（暂停时间能保证短至分时系统的个别时间片粒度）只影响 GC 线程而完全避免阻塞应用线程的实现很少，像 Asul C4 。代价是感人的内存使用率。
C/C++之类用全局堆之类实现的自由存储一样不能完全避免对全局共享的分配器内部管理数据结构加锁而可能暂停，但是任何靠谱的实现中这个暂停相对几乎所有 GC 都非常短而基本可以忽略。一些实现如 snmalloc 在同一个线程中的分配和释放可以完全不暂停其它线程。用户实现的只对特定线程可用的分配器可以不影响其它线程。
以上 GC 专指全局 tracing GC 。多实例 GC 堆和引用计数对整个应用的影响在此都可以视同后者。
当然如果程序是单线程的，那么不管是 GC 还是确定性分配器都会直接阻塞，因为没什么实现无聊到在释放算法里实现分时多任务。

@Kould 即使使用得当，不限深度的嵌套数据结构集中释放也很容易出现高延迟的问题。（这不属于使用不当，因为语言允许轻易地构造这种对象。）
实际上不容易观察到类似的问题，是因为在此之前，大多数 naive 实现在递归调用释放资源的例程中就直接爆栈了（

某语言对对象标识 0 代，1 代 ，N 代，应该是防止这些的

广义的讲，当你开始使用智能指针的时候，你就已经开始使用垃圾回收了

狭义的说，当前理论上有无暂停的 gc 算法，但是工程实现难度过大，一般还是会选择引入极短时间的暂停（如 Zing JVM ）

感觉鱼与熊掌不可兼得，自动化内存管理和手动内存管理各有利弊。手动内存管理好处是你就是上帝，可以控制任何东西，坏处是容易出问题（因为人容易出问题），这也是为啥 Linux 大部分漏洞都是内存安全问题方面的。自动化内存管理可以让一般开放人员无关心内存这种相对底层的问题，让开发人员更专注于业务开发，但是对于一些比较复杂的场景，如果垃圾收集器不能够很好的处理，则就是漫长的 GC 调优之路了。不过现在垃圾收集器也慢慢在发展，有的可以自适应了，不再需要我们去调整各种 GC 参数来获得更良好的性能。

@Cbdy 这种 zero pause gc 通常对 ram 要求都比较高。zing 要求至少 64g ram

如果一个实例 max heap 就是 10 几 g

老老实实用 g1 算了

会暂停，但是现代 GC 暂停时间都很短
毫秒级经典垃圾收集器：Garbage First (G1)
亚毫秒级低延迟垃圾收集器：Shenandoah 、ZGC

徹底解剖「 G1GC 」実装編 http://www.narihiro.info/ebook/g1gc-impl-20120914.pdf

上面很多楼已经说过了，哪怕是有 GC 的语言，现代垃圾回收器都会 pauseless 的类型。不会使主线程堵塞。
至于 C/C++/Rust 之类的语言，其实回收内存的时候已经不能称为暂停。因为这个是可预知。只能算成是程序 /函数运行的成本。更类似于你计算一个复杂的问题，函数没法立刻返回结果。

现在的过 gc 一般都不会暂停了