.Net 与 Java 垃圾收集器 [英] .Net vs Java Garbage Collector

问题描述

有人知道 Java 和 .Net 垃圾收集器之间的主要区别吗?网络搜索并没有透露太多，这是一个测试中提出的问题.

Does anyone know the major differences between the Java and .Net garbage collectors? A web search has not revealed much, and it was a question that came up in a test.

推荐答案

区别在于 CLR (.Net) GC 和 JVM GC，而不是语言本身.两者都可能发生变化，并且它们的行为规范松散，以允许在不影响程序正确性的情况下进行更改.

The difference is between the CLR (.Net) GC and the JVM GC rather than the languages themselves. Both are subject to change and the specification of their behaviour loose to allow this to be changed without it affecting the correctness of programs.

存在一些历史差异，主要是由于 .Net 的设计借鉴了 java(和其他基于 gc 的平台)的演变.在下文中，不要假设 .Net 在某些方面优于它，因为它从一开始就包含功能，它只是后来出现的结果.

There are some historical differences largely due to .Net being designed with lessons from the evolution of the java (and other gc based platforms). In the following do not assume that the .Net one was in some way superior because it included functionality from the beginning, it is simply the result of coming later.

一个显着的公开可见差异是 MS GC 暴露了它的代际性质(通过 GC api)，这可能会在一段时间内保持不变，因为这是基于大多数程序表现出的行为的明显方法:大多数分配是非常短暂的.

A notable publicly visible difference is that the MS GC exposes its generational nature (via the GC api) this is likely to remain true for some time since this is an obvious approach to take based on the behaviour that most programs exhibit: Most allocations are extremely short lived.

最初的 JVM 没有分代垃圾收集器，尽管这个特性被迅速添加.SunOracle 和其他人实现的第一代收集器往往是 Mark and Sweep.人们意识到标记-扫描-压缩方法将导致更好的内存局部性，从而证明额外的复制开销是合理的.CLR 运行时以这种行为首次亮相.

Initial JVM's did not have generational garbage collectors though this feature was swiftly added. The first generational collectors implemented by SunOracle and others tended to be Mark and Sweep. It was realized that a mark-sweep-compact approach would lead to much better memory locality justifying the additional copying overhead. The CLR runtime debuted with this behaviour.

SunOracle 和 Microsoft 的 GC 实施精神"之间的区别之一是可配置性.

A difference between SunOracle's and Microsoft's GC implementation 'ethos' is one of configurability.

Sun 提供了大量选项(在命令行中)来调整 GC 的各个方面或在不同模式之间切换.许多选项都属于 -X 或 -XX 以表明它们缺乏跨不同版本或供应商的支持.相比之下，CLR 几乎没有提供可配置性.您唯一真正的选择是使用分别针对吞吐量和延迟进行优化的服务器或客户端收集器.

Sun's provides a vast number of options (at the command line) to tweaks aspects of the GC or switch it between different modes. Many options are of the -X or -XX to indicate their lack of support across different versions or vendors. The CLR by contrast provides next to no configurability; your only real option is the use of the server or client collectors which optimise for throughput verses latency respectively.

两家公司(以及开源实施)都在积极研究 GC 策略) 以及 pre-tenuring 方法，它们试图避免将某些分配放入伊甸园生成.

Active research in GC strategies is ongoing in both companies (and in open source implementations) current approaches being used in the most recent GC implementations are per thread eden areas (improving locality and allowing the eden collection to potentially not cause a full pause) as well as pre-tenuring approaches, which try to avoid placing certain allocations into the eden generation.

这篇关于.Net 与 Java 垃圾收集器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！