C#:IDisposable 和 析构函数

分享
C#:IDisposable 和 析构函数

C# 中有两种释放资源的方式:实现 IDisposable 或使用析构函数。通常,必须在特定时间释放资源的场景中,我们实现 IDisposable,像这样:

public class ExampleDispose : IDisposable
{
    // 非托管资源
    private IntPtr _handle;
    // 使用的其它托管资源
    private readonly Stream _stream;
    private bool disposed = false;

    public ExampleDispose(Stream stream, IntPtr handle)
    {
        this._stream = stream;
        this._handle = handle;
    }

    public void Dispose()
    {
        if (disposed)
        {
            return;
        }
        disposed = true;

        // 调用其它托管资源的Dispose
        _stream.Dispose();

        // 释放非托管资源
        CloseHandle(_handle);
        _handle = IntPtr.Zero;
    }

    [System.Runtime.InteropServices.DllImport("Kernel32")]
    private extern static Boolean CloseHandle(IntPtr handle);
}

通常来说,如果你在使用完后正确调用了 Dispose() 方法或者使用了 using,就可以正确释放资源。

其他情况,则需要依赖 GC 在回收托管对象前先释放引用的非托管资源,一个实现了 IDisposable 接口和具有析构函数的类可能如下所示:

public class ExampleDispose : IDisposable
{
    // 非托管资源
    private IntPtr _handle;
    // 使用的其它托管资源
    private readonly Stream _stream;
    private bool disposed = false;

    public ExampleDispose(Stream stream, IntPtr handle)
    {
        this._stream = stream;
        this._handle = handle;
    }

    ~ExampleDispose()
    {
        // 此代码有异常情况,不要在生产环境使用
        Dispose();
    }

    public void Dispose()
    {
        if (disposed)
        {
            return;
        }
        disposed = true;
        
        // 调用其它托管资源的Dispose
        _stream.Dispose();

        // 释放非托管资源
        CloseHandle(_handle);
        _handle = IntPtr.Zero;
    }

    [System.Runtime.InteropServices.DllImport("Kernel32")]
    private extern static Boolean CloseHandle(IntPtr handle);
}

相比上部分代码,只是多增加了一个析构函数 ~ExampleDispose(),仔细观察它非常有意思,构造函数用于对象的创建,析构函数有点像构造函数,只是没有访问修饰符,且前面多了个 “~”,我们知道这个符号通常用于取反操作,构造函数取反,那就是“销毁函数”,也正如它所隐含的含义那样:GC 会在回收对象前调用析构函数来释放资源。现在,无论用户是否主动调用过 Dispose()~ExampleDispose() 都会在 GC 回收对象时被调用,如果用户主动释放过资源,那么 disposedtrue~ExampleDispose() 实际上调用 Dispose() 后直接返回,没有多于的操作,但是另一种情况,用户从未主动调用过 Dispose(),这时候在 GC 在调用 ~ExampleDispose() 时,会调用到 _stream.Dispose();。注意,这里可能会产问题,因为 GC 在回收对象时,对象内部其它对象可能已经被回收,这里 _stream 是有可能已经被回收的,因此,我们需要稍微更改一下,以实现在 GC 时不引用任何托管代码,为此,我们实现 dispose pattern

public class ExampleDispose : IDisposable
{
    // 非托管资源
    private IntPtr _handle;
    // 使用的其它托管资源
    private readonly Stream _stream;
    private bool disposed = false;

    public ExampleDispose(Stream stream, IntPtr handle)
    {
        this._stream = stream;
        this._handle = handle;
    }

    ~ExampleDispose()
    {
        Dispose(false);
    }

    public void Dispose()
    {
        Dispose(true);
    }

    // 如果 disposing 为 true, 则这是用户代码主动释放,
    // 可以安全的释放托管与非托管对象
    // 反之,则为 `GC` 回收对象时调用,这时不可引用任何托管对象
    protected virtual void Dispose(bool disposing)
    {
        if (disposed)
        {
            return;
        }
        disposed = true;

        if (disposing)
        {
            // 调用其它托管资源的Dispose
            _stream.Dispose();
        }

        // 释放非托管资源
        CloseHandle(_handle);
        _handle = IntPtr.Zero;
    }

    [System.Runtime.InteropServices.DllImport("Kernel32")]
    private extern static Boolean CloseHandle(IntPtr handle);
}

这样看起来,它已经能够正常工作了,但是还有个小问题:即使用户主动释放了资源,GC 还是会对 ~ExampleDispose() 进行调用。我们再对代码进行一次小更改,实现用户主动释放资源后,使得 GC 回收对象时不再调用 ~ExampleDispose()

public class ExampleDispose : IDisposable
{
    // 非托管资源
    private IntPtr _handle;
    // 使用的其它托管资源
    private readonly Stream _stream;
    private bool disposed = false;

    public ExampleDispose(Stream stream, IntPtr handle)
    {
        this._stream = stream;
        this._handle = handle;
    }

    ~ExampleDispose()
    {
        Dispose(false);
    }

    public void Dispose()
    {
        Dispose(true);
        // 调用 GC.SuppressFinalize 将该对象从终结队列中移除,
        // 并防止该对象的终结代码再次执行。
        GC.SuppressFinalize(this);
    }

    // 如果 disposing 为 true, 则这是用户代码主动释放,
    // 可以安全的释放托管与非托管对象
    // 反之,则为 `GC` 回收对象时调用,这时不可引用任何托管对象
    protected virtual void Dispose(bool disposing)
    {
        if (disposed)
        {
            return;
        }
        disposed = true;

        if (disposing)
        {
            // 调用其它托管资源的Dispose
            _stream.Dispose();
        }

        // 释放非托管资源
        CloseHandle(_handle);
        _handle = IntPtr.Zero;
    }

    [System.Runtime.InteropServices.DllImport("Kernel32")]
    private extern static Boolean CloseHandle(IntPtr handle);
}

Reference

阅读更多

以太坊黑暗森林-抢跑(front running)

以太坊黑暗森林-抢跑(front running)

前言 鸽了很久之后的今天突然心血来潮,准备写一个系列:以太坊黑暗森林,它介绍以太坊生态上的各种奇思妙想和逆天的攻击方式,会从简单的、常见的攻击方式开始介绍。取这个名字是因为我接触以太坊不久后看的一篇文章 Ethereum is a Dark Forest ,让我想起了《三体》小说中刘慈欣描述的黑暗森林,以太坊是一个弱肉强食的、没有规则的世界,猎人们总是躲在背后监听所有的交易,一旦发现猎物,它们会把它的血给吸干。 开盘抢币 相信进入以太坊生态的韭菜们,一定有过在 uniswap 上买刚开盘新币的经历,新开盘的币,一般会上涨几倍甚至十几倍,越早买入则越能低价买入。你守着时间,等着项目方添加流动性后第一时间买入代币,但是你发现,无论你的手速多块,总是看到一开盘,价格已经飚了几倍,你骂骂咧咧,开始不断拉高 gas 费用,尝试继续买入,但是你眼睁睁的看着代币涨到十倍,自己的交易却一直失败,你开始怀疑项目方自己抢跑,怀疑项目方捣鬼:肯定是项目方吃相难看,用老鼠仓提前买了。另一些聪明人,研究了以太坊的基本技术,他们在 ethscan

By FatTiger
ThreadLocal引发的灾难

ThreadLocal引发的灾难

在 Java 里有个称之为线程本地变量的类型叫做 ThreadLocal,它与 ThreadLocal 之于 C# 中是一样的作用,可以在线程范围内设置变量,这个变量只会在当前线程可被访问,但是它们有一点不同的是,在 Java 中,当你设置好变量后,在线程使用完毕回到线程池之前,需要手动调用 ThreadLocal.remove() 方法去清除线程本地变量,否则变量随着线程回到线程池,并且在下次使用此线程时此变量继续存在,而在 C# 中,线程回到线程池时会自动清除本地变量,因此无需手动去清除。 我们的业务有这样一个场景:某个业务 UserService 类中,具有多个方法会频繁(甚至循环)调用一个获取用户标签的接口,具体原因是因为某些方法会进行递归,数据结构有个树状结构,因此,为了优化接口响应时间以及看起来不那么蠢,我使用 ThreadLocal 将用户标签接口的返回数据存储到当前线程,因为在单个请求中,多次调用此接口获取数据是不必要的,它看起来像这样: /** * 此静态变量ThreadLocal会为每个线程创建本地副本, 因此USER_TAGS_THREAD_

By FatTiger
我在币安智能链的日子-区块链基础

我在币安智能链的日子-区块链基础

区块和链 无论是比特币还是以太坊,都是具有一个个区块(称之为Block)的链式结构,学过<数据结构>的肯定明白链表,区块链就像一个链表,每个区块都存储上一个区块哈希。 链(称之为Chain),有非常多的链,他们的协议不同,技术也不尽相同,比特币网络是一个链,以太坊网络是另一个链,每个链都有自己的目标(甚至目标只是为了圈钱),每个链也都有自己的代币,比特币网络的代币是比特币,每次交易都需要比特币作为手续费,以太坊网络代币是以太币,每次在以太坊网络的交易都需要以太币作为手续费。所以,链实际上作为基础设施,非常多的团队喜欢创建新的链,但是一个链光有网络光有代币不行,没有生态,很难成功。 币安智能链(Binance Smart Chain:BSC) 我的主要操作都是在BSC上,没有其它原因,只因为一个穷字。在BTC网络交易,需要BTC用作手续费,这个我可用不起,在以太坊(Ethereum)网络交易,需要以太币(ETH)作为用作手续费,按照以太币目前(

By FatTiger
All about ExecutionContext and SynchronizationContext

All about ExecutionContext and SynchronizationContext

前言 这篇文章深入探讨了ExecutionContext和SynchronizationContext, 这是大部分开发人员都不需要了解的 .NET 高级领域. SynchronizationContext 我最早关于 SynchronizationContext 了解可能是在 WindowsForm 程序, 当我错误的在其它线程去更新 UI 控件时, 总会出现一个异常 Cross-thread operation not valid: Control accessed from a thread other than the thread it was created on 翻译过来即 跨线程操作无效:控件从创建它的线程以外的线程访问, 例如这个代码片段: private void button_Click(object sender, EventArgs e) { Task.Run(() => { //异常: 跨线程操作无效:控件从创建它的线程以外的线程访问

By FatTiger