引用类型赋值为null与加速垃圾回收

简介:

在标准的Dispose模式中(见前一篇博客C#中标准Dispose模式的实现”),提到了需要及时释放资源,却并没有进一步细说让引用等于null是否有必要。

有一些人认为等于null可以帮助垃圾回收机制早点发现并标识对象是垃圾。其他人则认为这没有任何帮助。是否赋值为null的问题首先在方法的内部被人提起。现在,为了更好的阐述提出的问题,我们来撰写一个Winform窗体应用程序。如下:

 
 
private void button1_Click( object sender, EventArgs e)
{
Method1();
Method2();
}

private void button2_Click( object sender, EventArgs e)
{
GC.Collect();
}

private void Method1()
{
SimpleClass s
= new SimpleClass( " method1 " );
s
= null ;
//其它无关工作代码(这条注释源于回应回复的朋友的质疑)
}
private void Method2()
{
SimpleClass s
= new SimpleClass( " method2 " );
}
}

class SimpleClass
{
string m_text;

public SimpleClass( string text)
{
m_text
= text;
}

~ SimpleClass()
{
MessageBox.Show(
string .Format( " SimpleClass Disposed, tag:{0} " , m_text));
}
}

先点击按钮1,再点击按钮2释放,我们会发现:

q 方法Method2中的对象先被释放,虽然它在Method1之后被调用;

q 方法Method2中的对象先被释放,虽然它不像Method1那样为对象引用赋值为null;

在CLR托管应用程序中,存在一个“根”的概念,类型的静态字段、方法参数以及局部变量都可以作为“根”存在(值类型不能作为“根”,只有引用类型的指针才能作为“根”)。

上面的两个方法中各自的局部变量,在代码运行过程中会在内存中各自创建一个“根”.在一次垃圾回收中,垃圾回收器会沿着线程栈上行检查“根”。检查到方法内的“根”时,如果发现没有任何一个地方引用了局部变量,则不管是否为变量赋值为null,都意味着该“根”已经被停止掉。然后垃圾回收器发现该根的引用为空,同时标记该根可被释放,这也表示着Simple类型对象所占用的内存空间可被释放。所以,在上面的这个例子中,为s指定为null丝毫没有意义(方法的参数变量也是这种情况)。

更进一步的事实是,JIT编译器是一个经过优化的编译器,无论我们是否在方法内部为局部变量赋值为null,该语句都会被忽略掉

s = null;

在我们将项目设置为Release模式下,上面的这行代码将根本不会被编译进运行时内。

正式由于上面这样的分析,很多人认为为对象赋值为null完全没有必要。但是,在另外一种情况下,却要注意及时为变量赋值为null。那就是类型的静态字段。为类型对象赋值为null,并不意味着同时为类型的静态字段赋值为null:

 
 
private void button1_Click( object sender, EventArgs e)
{
SimpleClass s
= new SimpleClass( " test " );
}

private void button2_Click( object sender, EventArgs e)
{
GC.Collect();
}
}

class SimpleClass
{
static AnotherSimpleClass asc = new AnotherSimpleClass();
string m_text;

public SimpleClass( string text)
{
m_text
= text;
}

~ SimpleClass()
{
// asc = null;
MessageBox.Show( string .Format( " SimpleClass Disposed, tag:{0} " , m_text));
}
}

class AnotherSimpleClass
{
~ AnotherSimpleClass()
{
MessageBox.Show(
" AnotherSimpleClass Disposed " );
}
}

以上代码运行的结果使我们发现,当执行垃圾回收,当类型SampleClass对象被回收的时候,类型的静态字段asc并没有被回收。

必须要将SimpleClass的终结器中注释的那条代码启用。

字段asc才能被正确释放(注意,要点击两次释放按钮。这是因为一次垃圾回收会仅仅首先执行终结器)。之所以静态字段不被释放(同时赋值为null语句也不会像局部变量那样被运行时编译器优化掉),是因为类型的静态字段一旦被创建,该“根”就一直存在。所以垃圾回收器始终不会认为它是一个垃圾。非静态字段不存在这个问题。将asc改为非静态,再次运行上面的代码,会发现asc随着类型的释放而被释放。

上文代码的例子中,让asc=null是在终结器中完成的,实际工作中,一旦我们感觉到自己的静态引用类型参数占用内存空间比较大,并且使用完毕后不再使用,则可以立刻将其赋值为null。这也许并不必要,但这绝对是一个好习惯。试想一下在一个大系统中,那些时不时在类型中出现的静态变量吧,它们就那样静静地呆在内存里,一旦被创建,就永远不离开,越来越多,越来越多……




















本文转自cnn23711151CTO博客,原文链接:http://blog.51cto.com/cnn237111/541051 ,如需转载请自行联系原作者


相关文章
|
缓存 算法 Java
Java面试题:深入探究Java内存模型与垃圾回收机制,Java中的引用类型在内存管理和垃圾回收中的作用,Java中的finalize方法及其在垃圾回收中的作用,哪种策略能够提高垃圾回收的效率
Java面试题:深入探究Java内存模型与垃圾回收机制,Java中的引用类型在内存管理和垃圾回收中的作用,Java中的finalize方法及其在垃圾回收中的作用,哪种策略能够提高垃圾回收的效率
229 1
|
存储 缓存 算法
JVM第三讲:深入理解java虚拟机之垃圾回收算法?CMS垃圾回收的基本流程?对象引用类型?
JVM第三讲:深入理解java虚拟机之垃圾回收算法?CMS垃圾回收的基本流程?对象引用类型?
843 0
|
存储 C#
C# 值类型与引用类型 null与可空类型
本文目录 1. 值类型与引用类型 2. null的含义 3. 可空类型
318 0
|
存储 算法 Java
G1原理—6.G1垃圾回收过程之Full GC
本文详细探讨了G1垃圾回收器对Full GC(FGC)的优化处理,涵盖FGC的前置处理、整体流程及并行化改进。重点分析了传统FGC串行化的局限性以及G1通过Region分区和RSet机制实现并行标记的优势,包括任务窃取提升效率、跨分区压缩以生成空闲Region等技术细节。此外,文章还介绍了G1的新特性——字符串去重优化,通过判断char数组一致性减少重复字符串占用内存,从而提升内存使用效率。总结部分全面回顾了G1在FGC中的各项优化措施及其带来的性能改善。
G1原理—6.G1垃圾回收过程之Full GC
|
存储 算法 Java
G1原理—5.G1垃圾回收过程之Mixed GC
本文介绍了G1的Mixed GC垃圾回收过程,包括并发标记算法详解、三色标记法如何解决错标漏标问题、SATB如何解决错标漏标问题、Mixed GC的过程、选择CollectSet的算法
G1原理—5.G1垃圾回收过程之Mixed GC
|
存储 算法 Java
G1原理—4.G1垃圾回收的过程之Young GC
本文详细解析了G1垃圾回收器中YGC(Young Generation Collection)的完整流程,包括并行与串行处理阶段。内容涵盖YGC相关参数设置、YGC与Mixed GC及FGC的关系、新生代垃圾回收的具体步骤(如标记存活对象、复制到Survivor区、动态调整Region数量等),以及并行阶段的多线程操作和串行阶段的关键任务(如处理软引用、整理卡表、重构RSet)。
G1原理—4.G1垃圾回收的过程之Young GC
|
算法 网络协议 Java
【JVM】——GC垃圾回收机制(图解通俗易懂)
GC垃圾回收,标识出垃圾(计数机制、可达性分析)内存释放机制(标记清除、复制算法、标记整理、分代回收)

热门文章

最新文章