熟悉而陌生的新朋友——IAsyncDisposable

歡迎關注我們的新博客——碼睿鴨

在.NET Core 3.0的版本更新中，官方我們帶來了一個新的接口 IAsyncDisposable。

小夥伴一看肯定就知道，它和.NET中原有的IDisposable接口肯定有着密不可分分的關係，且一定是它的異步實現版本。

那麼.NET是爲什麼要在 .NET Core 3.0 （伴隨C# 8） 發佈的同時，帶來該接口呢？還有就是該異步版本和原來的IDispose有着什麼樣的區別呢？到底在哪種場景下我們能使用它呢？

帶着這些問題，我們今天一起來認識一下這位"新朋友" —— IAsyncDisposable。

爲了更好的瞭解它，讓我們先來回顧一下.NET中的資源釋放：

.NET的資源釋放

由於.NET強大的GC，對於託管資源來說（比如C#的類實例），它的釋放往往不需要開發人員來操心。

但是在開發過程中，有時候我們需要涉及到非託管的資源，比如I/O操作，將緩衝區中的文本內容保存到文件中、網絡通訊，發送數據包等等。

由於這些操作GC沒有辦法控制，所以也就沒有辦法來管理它們的生命週期。如果使用了非託管資源之後，沒有及時進行釋放資源，那麼就會造成內存的泄漏問題。

而.NET爲我們提供了一些手段來進行資源釋放的操作：

析構函數

析構函數在C#中是一個語法糖，在構造函數前方加一個～符號即代表使用析構函數。

public class ExampleClass
{
public ExampleClass()
{
}

~ExampleClass()	// 析構函數
{
// 釋放非託管資源
}
}

當一個類申明瞭析構函數了之後，GC將會對它進行特殊的處理，當該實例的資源被GC回收之前會調用析構函數。（該部分內容本文將不做過多介紹）

雖然析構函數方法在某些需要進行清理的情況下是有效的，但它有下面兩個嚴重的缺點：

只有在GC檢測到某個對象可以被回收時纔會調用該對象的終結方法，這發生在不再需要資源之後的某個不確定的時間。這樣一來，開發人員可以或希望釋放資源的時刻與資源實際被終結方法釋放的時刻之間會有一個延遲。如果程序需要使用許多稀缺資源（容易耗盡的資源）或不釋放資源的代價會很高（例如，大塊的非託管內存），那麼這樣的延遲可能會讓人無法接受。
當CLR需要調用終結方法時，它必須把回收對象內存的工作推遲到垃圾收集的下一輪（終結方法會在兩輪垃圾收集之間運行）。這意味着對象的內存會在很長一段時間內得不到釋放。

因此，如果需要儘快回收非託管資源，或者資源很稀缺，或者對性能要求極高以至於無法接受在GC時增加額外開銷，那麼在這些情況下完全依靠析構函數的方法可能不太合適。

而框架提供了IDisposable接口，該接口爲開發人員提供了一種手動釋放非託管資源的方法，可以用來立即釋放不再需要的非託管資源。

IDisposable

從.NET Framework 1.1開始，.NET就爲我們提供了IDispose接口。

使用該接口，我們可以實現名爲Dispose的方法，進行一些手動釋放資源的操作（包括託管資源和非託管資源）。

public class ExampleClass:IDisposable
{
private Stream _memoryStream = new MemoryStream();

public ExampleClass()
{
}

public void Dispose()
{
// 釋放資源
myList.Clear();
myData = null;
_memoryStream.Dispose();	
}
}

在C#中，我們除了可以手動調用 xx.Dispose()方法來觸發釋放之外，還可以使用using的語法糖。

當我們在 visual studio 中添加IDisposable接口時，它會提示我們使用是否使用“釋放模式”：

“釋放模式”所生成的代碼如下：

protected virtual void Dispose(bool disposing)
{
if (!disposedValue)
{
if (disposing)
{
// TODO: 釋放託管狀態(託管對象)
}

// TODO: 釋放未託管的資源(未託管的對象)並重寫終結器
// TODO: 將大型字段設置爲 null
disposedValue = true;
}
}

// // TODO: 僅當“Dispose(bool disposing)”擁有用於釋放未託管資源的代碼時才替代終結器
// ~ExampleClass()
// {
// // 不要更改此代碼。請將清理代碼放入“Dispose(bool disposing)”方法中
// Dispose(disposing: false);
// }

public void Dispose()
{
// 不要更改此代碼。請將清理代碼放入“Dispose(bool disposing)”方法中
Dispose(disposing: true);
GC.SuppressFinalize(this);
}

釋放資源的代碼被放置在 Dispose(bool disposing) 方法中，你可以選用析構函數或者 IDisposable 來進行調用該方法。

這裏說一下：在 IDisposable 的實現中，有一句 GC.SuppressFinalize(this);。這句話的意思是，告訴GC，不需要對該類的析構函數進行單獨處理了。也就是說，該類的析構函數將不會被調用。因爲資源已經在 Dispose() 中被我清理了。

異步時代

從.NET Core開始，就意味着.NET來到了一個全新的異步時代。無論是各種基礎類庫（比如System.IO）、AspNet Core、還是EFCore..... 它們都支持異步操作，應該說是推薦異步操作。

在今天，假如一個新項目沒有使用 await 和 async。你都會覺得自己在寫假代碼😂。

現在越來越多的開發者都愛上了這種異步方式：不阻止線程的執行，帶來高性能的同時還完全不需要更改原有的編碼習慣，可謂是兩全其美。

所以從.NET Core 開始到現在的.NET 5 ，每一次版本更迭都會有一批API提供了異步的版本。

IAsyncDisposable的誕生

爲了提供這樣一種機制讓使用者能夠執行資源密集型的處置操作，而不會長期阻塞GUI應用程序的主線程，我們讓操作成爲了異步。

同樣，釋放資源的時候我們能否成爲異步呢？假如一次釋放操作會佔耗費太多的時間，那爲什麼我們不讓它去異步執行呢？

爲了解決這一問題，同時更好的完善.NET異步編程的體驗，IAsyncDisposable誕生了。

它的用法與IDisposable非常的類似：

public class ExampleClass : IAsyncDisposable
{
private Stream _memoryStream = new MemoryStream();

public ExampleClass()
{

}

public async ValueTask DisposeAsync()
{
await _memoryStream.DisposeAsync();
}
}

當然，using的語法糖同樣適用於它。不過，由於它是異步編程的風格，在使用時記得添加await關鍵字：

await using var s = new ExampleClass()
{
// doing
};

當然在 C# 8 以上，我們可以使用using作用域的簡化寫法：

await using var s = new ExampleClass();
// doing

IAsyncDisposable與IDisposable的選擇

有一個關鍵點是： IAsyncDisposable 其實並沒有繼承於 IDisposable。

這就意味着，我們可以選擇兩者中的任意一個，或者同時都要。

那麼我們到底該選擇哪一個呢？

這個問題其實很類似於EF剛爲大家提供SaveChangesAsync方法的時候，到底我們該選用SaveChangesAsync還是SaveChanges呢？

在以往同步版本的代碼中，我們往往會選擇SaveChanges同步方法。當來到了異步的環境，我們往往會選擇SaveChangesAsync。

所以在AspNet Core這個全流程異步的大環境下，我們的代碼潛移默化的就會更改爲SaveChangesAsync。

而IAsyncDisposable也是同理的，當我們處於異步的環境中，所使用的資源提供了異步釋放的接口，那麼我們肯定就會自然而然的使用IAsyncDisposable。

在.NET 5 之後，大部分的類都具有了IAsyncDisposable的實現。比如：

Utf8JsonWriter、StreamWriter這些與文件操作有關的類；
DbContext這類數據庫操作類
Timer
依賴注入的ServiceProvider
………………

接下來的.NET版本中，我們也會看到AspNet Core中的Controller 等對於IAsyncDisposable提供支持。

可以預測是，在未來的.NET發展中，全異步的發展是必然的。後面越來越的已有庫會支持異步的所有操作，包括IAsyncDisposable的使用也會越來越頻繁。

Asp Net Core 依賴注入中的IAsyncDisposable

對於咱們使用AspNet Core的開發人員來說，我們在大多數情況下都會依賴於框架所提供的依賴注入功能。

而依賴注入框架，會在作用域釋放的時候，自動去調用所注入服務的釋放接口IDisposable。

比如我們把 DbContext 注入之後，其實就只管使用就行了，從來不會關心它的Dispose問題。相對於傳統using(var dbContext = new MyDbContext)的方式要省心很多，也不會擔心忘記寫釋放而導致的數據庫連接未釋放的問題。

那麼，當IAsyncDisposable出現之後呢？會出現什麼情況：

public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();

services.AddScoped<DemoDisposableObject>();	// 注入測試類	
}


public class DemoDisposableObject : IAsyncDisposable
{
public ValueTask DisposeAsync()
{
code here 
// 當完成一次http 請求後，該方法會自動調用
}
}

當我們實現了IAsyncDisposable之後，會被自動調用。

那麼如果 IAsyncDisposable 和 IDisposable 一同使用呢？

public class DemoDisposableObject : IAsyncDisposable,IDisposable
{
public void Dispose()
{
code here 
}

public ValueTask DisposeAsync()
{
code here 
}
}

這樣的結果是：只有DisposeAsync方法會被調用。

爲什麼會有這樣的結果呢？讓我們一起來扒開它的面紗。

以下代碼位於 AspNet Core源碼

public class RequestServicesFeature : IServiceProvidersFeature, IDisposable, IAsyncDisposable
{
public IServiceProvider RequestServices
{
get
{
if (!_requestServicesSet && _scopeFactory != null)
{
_scope = _scopeFactory.CreateScope();
……………………
}
return _requestServices!;
}
}

public ValueTask DisposeAsync()
{
switch (_scope)
{
case IAsyncDisposable asyncDisposable:
var vt = asyncDisposable.DisposeAsync();
………………
break;
case IDisposable disposable:
disposable.Dispose();
break;
}

……………………
return default;
}

public void Dispose()
{
DisposeAsync().AsTask().GetAwaiter().GetResult();
}
}

爲了方便起見，我省略了部分代碼。這裏的關鍵代碼在於： DisposeAsync()方法，它會在內部進行判斷，IServiceScope是否爲IAsyncDisposable類型。如果是，則會採用它的IServiceScope的異步釋放方法。

所以本質上還是回到了官方依賴注入框架中IServiceScope的實現：

以下代碼位於 DependencyInjection源碼

internal sealed class ServiceProviderEngineScope : IServiceScope, IServiceProvider, IAsyncDisposable, IServiceScopeFactory
{
public ValueTask DisposeAsync()
{
List<object> toDispose = BeginDispose();

if (toDispose != null)
{
try
{
for (int i = toDispose.Count - 1; i >= 0; i--)
{
object disposable = toDispose[i];
if (disposable is IAsyncDisposable asyncDisposable)
{
ValueTask vt = asyncDisposable.DisposeAsync();
if (!vt.IsCompletedSuccessfully)
{
return Await(i, vt, toDispose);
}

// If its a IValueTaskSource backed ValueTask,
// inform it its result has been read so it can reset
vt.GetAwaiter().GetResult();
}
else
{
((IDisposable)disposable).Dispose();
}
}
}
catch (Exception ex)
{
return new ValueTask(Task.FromException(ex));
}
}

return default;
}
}

可以看出新版本的IServiceScope實現一定是繼承了IAsyncDisposable接口，所以在上面的AspNet Core的代碼裏，它一定會調用IServiceScope的DisposeAsync()方法。

而IServiceScope的默認實現在異步釋放時會進行判斷：如果注入的實例爲IAsyncDisposable則調用DisposeAsync()，否則判斷是否爲IDisposable。

這也解釋了爲什麼我們在上面同時實現兩個釋放接口，卻只有異步版本的會被調用。

總結

在上面的文章中，我們瞭解到IAsyncDisposable作爲.NET異步發展中一個重要的新接口，在應用上會被越來越頻繁的使用，它將逐步完善.NET的異步生態。

當存在下方的情況時，我們應該優先考慮來使用它：

當內部擁有的資源具有對IAsyncDisposable的實現（比如Utf8JsonWriter等），我們可以採用使用IAsyncDisposable來對他們進行釋放。
當在異步的大環境下，新編寫一個需要釋放資源的類，可以優先考慮使用IAsyncDisposable。

現在.NET的很多類庫都已經同時支持了IDisposable和IAsyncDisposable。而從使用者的角度來看，其實調用任何一個釋放方法都能夠達到釋放資源的目的。就好比DbContext的SaveChanges和SaveChangesAsync。

但是從未來的發展角度來看，IAsyncDisposable會成使用的更加頻繁。因爲它應該能夠優雅地處理託管資源，而不必擔心死鎖。

而對於現在已有代碼中實現了IDisposable的類，如果想要使用IAsyncDisposable。建議您同時實現兩個接口，已保證使用者在使用時，無論調用哪個接口都能達到效果，而達到兼容性的目的。

類似於下方代碼：

節選自Stream類的源碼

public void Dispose() => Close();

public virtual void Close()
{

Dispose(true);
GC.SuppressFinalize(this);
}

public virtual ValueTask DisposeAsync()
{
try
{
Dispose();
return default;
}
catch (Exception exc)
{
return ValueTask.FromException(exc);
}
}

最後的最後，希望 點贊，關注，一鍵三連 走一波。

熟悉而陌生的新朋友——IAsyncDisposable

.NET的資源釋放

析構函數

IDisposable

異步時代

IAsyncDisposable的誕生

IAsyncDisposable與IDisposable的選擇

Asp Net Core 依賴注入中的IAsyncDisposable

總結

杭州的 IT 崩盤了麼？

開源高性能結構化日誌模塊NanoLog

Python 潮流週刊#55：分享 9 個高質量的技術類信息源！

Azure Virtual Network (22) 多訂閱使用Azure DNS解析問題 Windows Azure Platform 系列文章目錄

【簡寫Mybatis-02】註冊機的實現以及SqlSession處理

手繪二維碼

.NET藉助虛擬網卡實現一個簡單異地組網工具

【5min+】閃電光速拳？ .NetCore 中的Span

【5min+】秋名山的競速。 ValueTask 和 Task

熟悉而陌生的新朋友——IAsyncDisposable

微服務場景下的數據一致性解決方案 - saga

如何運用領域驅動設計 - 工作單元

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結