c# .net中using的使用

在這里插入圖片描述

using示例代碼

示例代碼1：

using HttpContent httpContent = new StringContent(postData, Encoding.UTF8);

示例代碼2：

using (var process = Process.Start(info))
{output = process.StandardOutput.ReadToEnd();
}

示例代碼1寫法：

using HttpContent httpContent = new StringContent(postData, Encoding.UTF8);

語法分析：

這是 C# 8.0 引入的 using 聲明語法，其本質是 隱式資源管理，等價于：

HttpContent httpContent = new StringContent(postData, Encoding.UTF8);
httpContent.Dispose(); // 在作用域結束時自動調用

特點：

  • 資源管理：在 httpContent 的作用域結束時自動調用 Dispose()。
  • 適用場景：適用于一次性使用的資源（如 HttpContent、文件流等）。
  • 優勢：
    • 代碼簡潔：無需顯式嵌套 using 代碼塊。
    • 可讀性高：資源生命周期與變量作用域一致，邏輯清晰。

示例代碼2寫法：

using (var process = Process.Start(info))
{output = process.StandardOutput.ReadToEnd();
}

語法分析：

這是 傳統 using 語句，顯式管理資源，等價于：

var process = Process.Start(info);
try
{output = process.StandardOutput.ReadToEnd();
}
finally
{process.Dispose(); // 確保資源釋放
}

特點：

  • 資源管理：通過 using 代碼塊確保 Process 對象在退出時調用 Dispose()。
  • 適用場景：需要顯式控制資源釋放的場景（如進程管理、數據庫連接等）。
  • 優勢：
    • 強制資源釋放：即使發生異常，Dispose() 也會被調用。
    • 兼容性：適用于所有 C# 版本（包括 C# 8.0 之前的版本）。

注意事項：

  • 潛在問題：Process.Start() 可能返回 null（例如路徑錯誤或權限不足），需在 using 前檢查：
    var process = Process.Start(info);
if (process == null) return; // 處理異常情況
using (process)
{output = process.StandardOutput.ReadToEnd();
}

兩種寫法的核心區別

特性using 聲明（C# 8.0）傳統 using 語句
語法形式using T variable = new T();using (T variable = new T()) { ... }
資源釋放時機變量作用域結束時自動釋放using 代碼塊結束時自動釋放
代碼簡潔性更簡潔（尤其適合單行資源管理）需要顯式嵌套代碼塊
兼容性僅支持 C# 8.0 及以上版本所有 C# 版本兼容
適用場景簡單資源管理（如 HttpContent、文件流）復雜資源管理（如進程、數據庫連接）

使用建議

選擇 using 聲明（C# 8.0）的情況：

  • 資源生命周期與變量作用域一致：例如：
    using HttpClient client = new HttpClient();
var response = await client.GetAsync("https://example.com");
  • 代碼簡潔性優先：適合一次性使用的資源（如臨時文件流、HTTP 內容）。

選擇傳統 using 語句的情況：

  • 需要顯式控制資源釋放邏輯：例如：
    using (var process = Process.Start(info))
{process.WaitForExit();Console.WriteLine(process.ExitCode);
}
  • 兼容性要求：項目需要支持 C# 8.0 以下版本。
  • 資源管理涉及復雜操作：例如在 using 塊內需要多次調用資源的方法或屬性。

典型示例對比

using 聲明（C# 8.0）

using HttpContent content = new StringContent(jsonData, Encoding.UTF8, "application/json");
var response = await httpClient.PostAsync(url, content);

傳統 using 語句

using (var reader = new StreamReader(filePath))
{string line;while ((line = await reader.ReadLineAsync()) != null){Console.WriteLine(line);}
}

總結

  • 兩種寫法的本質相同：都是通過 IDisposable 接口確保資源釋放。
  • 語法差異：using 聲明更簡潔，傳統 using 語句更通用。
  • 選擇依據：
    • C# 8.0+ 且資源生命周期短 → 使用 using 聲明。
    • 兼容性或復雜邏輯 → 使用傳統 using 語句。

通過合理選擇，可以顯著提升代碼的可讀性和健壯性！

4個疑問？

問題1：這2種寫法是同一種寫法嗎？

不是同一種寫法。
它們的本質目標相同（確保資源釋放），但語法形式和適用場景不同：

  1. 第一種寫法（using HttpContent httpContent = new StringContent(...)）：
    • 是 C# 8.0 引入的 using 聲明語法，屬于 隱式資源管理。
    • 變量作用域結束時自動調用 Dispose()。
  2. 第二種寫法（using (var process = Process.Start(info)) { ... }）：
    • 是傳統的 using 語句，屬于 顯式資源管理。
    • 通過代碼塊控制資源釋放，即使發生異常也會確保 Dispose() 被調用。

問題2：它們分別具有什么樣的優勢？

1. using 聲明（C# 8.0）

優勢：

  • 代碼簡潔：無需嵌套代碼塊，直接聲明資源變量。
  • 可讀性高：資源生命周期與變量作用域一致，邏輯清晰。
  • 適用于簡單場景：適合一次性使用的資源（如 HttpContent、文件流等）。

示例：

using HttpContent content = new StringContent(jsonData, Encoding.UTF8, "application/json");
var response = await httpClient.PostAsync(url, content);
// content 在作用域結束時自動釋放

2. 傳統 using 語句

優勢：

  • 兼容性強：支持所有 C# 版本（包括 C# 8.0 之前的版本）。
  • 控制更靈活：可以在代碼塊內執行復雜邏輯，確保資源釋放。
  • 適用于復雜場景：適合需要顯式控制資源釋放的場景（如進程管理、數據庫連接等）。

示例：

using (var process = Process.Start(info))
{string output = process.StandardOutput.ReadToEnd();process.WaitForExit();
}
// process 在代碼塊結束時自動釋放

問題3：什么情況下用哪種方式？

選擇 using 聲明（C# 8.0）的情況：

  1. 項目使用 C# 8.0 或更高版本。
  2. 資源生命周期與變量作用域一致（如臨時創建的資源）。
  3. 追求代碼簡潔性（減少嵌套代碼塊）。

示例場景：

  • 創建 HttpContent 發送 HTTP 請求。
  • 打開臨時文件流讀取數據。

選擇傳統 using 語句的情況：

  1. 需要兼容 C# 8.0 之前的版本。
  2. 資源管理涉及復雜邏輯（如需要多次操作資源或處理異常）。
  3. 資源需要顯式控制釋放時機（如進程啟動后需等待執行完成）。

示例場景：

  • 啟動進程并讀取輸出（如調用 PowerShell 腳本）。
  • 使用數據庫連接時確保事務提交或回滾。

總結對比表

特性using 聲明（C# 8.0）傳統 using 語句
語法形式using T variable = new T();using (T variable = new T()) { ... }
資源釋放時機變量作用域結束時自動釋放代碼塊結束時自動釋放
代碼簡潔性更簡潔（適合單行資源管理）需要顯式嵌套代碼塊
兼容性僅支持 C# 8.0 及以上版本所有 C# 版本兼容
適用場景簡單資源管理（如 HttpContent、文件流）復雜資源管理（如進程、數據庫連接）

注意事項

  1. 確保資源正確釋放：

    • 無論哪種寫法，都要確保資源實現了 IDisposable 接口。
    • 對于 Process 類，需注意 Process.Start() 可能返回 null（如路徑錯誤或權限不足），需額外檢查。

  2. 避免資源泄漏：

    • 如果資源未正確釋放（如異常導致跳過 Dispose()），可能導致內存泄漏或系統資源耗盡。

  3. 結合實際需求選擇：

    • 如果項目使用 C# 8.0+ 且資源管理簡單，優先使用 using 聲明。
    • 如果需要兼容舊版本或處理復雜邏輯，使用傳統 using 語句。

通過合理選擇這兩種寫法，可以提升代碼的可讀性和健壯性！

問題4：我聲明一個字符串可以用using嗎？

如：

using string name="小妹";

在 C# 中，using 聲明（C# 8.0 引入的語法）僅適用于實現了 IDisposable 接口的對象。你提到的 using string name = "小妹"; 是 不符合語法規范的。

? 為什么不能用 using 聲明字符串？

原因：

  1. string 類型沒有實現 IDisposable 接口：

    • using 聲明的本質是 資源管理，只有實現了 IDisposable 的對象（如 Stream、HttpClient、Process 等）才需要通過 using 聲明自動釋放資源。
    • string 是簡單的值類型（引用類型但無資源管理需求），不需要也不支持 Dispose()。

  2. 編譯器會報錯：

    using string name = "小妹"; // ? 編譯錯誤：類型 'string' 必須為可處置類型（即實現 IDisposable 接口）

? using 聲明的正確用法

適用對象：
  • 實現了 IDisposable 的類型，例如：
    using HttpClient client = new HttpClient(); // 正確：HttpClient 實現了 IDisposable
using FileStream file = new FileStream("test.txt", FileMode.Open); // 正確：FileStream 實現了 IDisposable
錯誤示例：
using int number = 42; // ? int 沒有實現 IDisposable
using string name = "小妹"; // ? string 沒有實現 IDisposable

📌 普通變量的聲明方式

對于普通變量（如 string、int），應使用常規語法：

string name = "小妹"; // 正確：無需 using 聲明
int age = 20;

? 何時使用 using 聲明？

  • 需要自動釋放資源的場景，例如：
    1. 文件操作（FileStream、StreamReader）：
      using StreamReader reader = new StreamReader("data.txt");
string content = reader.ReadToEnd();
    2. 網絡通信（HttpClient、TcpClient）：
      using HttpClient client = new HttpClient();
string response = await client.GetStringAsync("https://example.com");
    3. 數據庫連接（SqlConnection）：
      using SqlConnection connection = new SqlConnection(connectionString);
connection.Open();

🔍 總結

語法是否合法說明
using string name = "小妹";? 否string 沒有實現 IDisposable 接口
using int number = 42;? 否int 是值類型，無需資源管理
using HttpClient client = ...? 是HttpClient 實現了 IDisposable，適合用 using 聲明

? 正確示例對比

1. 正確使用 using 聲明（資源管理）
using HttpClient client = new HttpClient();
var response = await client.GetAsync("https://example.com");
2. 普通變量聲明（無需 using）
string name = "小妹";
int age = 25;

?? 注意事項

  • 避免濫用 using 聲明：僅對需要釋放資源的對象使用，否則會導致代碼冗余或編譯錯誤。
  • 理解 IDisposable 的意義：只有需要顯式釋放非托管資源（如文件句柄、網絡連接）的對象才需要 using 聲明。

通過合理使用 using 聲明，可以顯著提升代碼的健壯性和可維護性！

這個 IDisposable 有什么特別之處？

IDisposable 是 .NET 中一個非常重要的接口，它用于顯式釋放非托管資源（如文件句柄、數據庫連接、網絡連接等），確保資源在不再需要時及時釋放，避免資源泄漏或內存泄漏。以下是它的核心特性和特別之處：

1. 核心作用：資源管理

  • 非托管資源：某些資源（如文件、套接字、GDI 對象）不在 .NET 的垃圾回收（GC）管理范圍內，需要顯式釋放。
  • 托管資源：由 GC 自動管理的對象（如普通類實例）不需要實現 IDisposable，但某些托管對象可能封裝了非托管資源（如 FileStream 封裝了文件句柄）。

2. IDisposable 接口的定義

public interface IDisposable
{void Dispose();
}
  • Dispose() 方法：用于釋放對象占用的資源。
    • 通常需要釋放非托管資源。
    • 可能還需要釋放其他托管資源（如果這些資源也實現了 IDisposable）。

3. IDisposable 的特別之處

(1) 顯式控制資源釋放

  • 避免依賴 GC：GC 的回收時機是不確定的，可能導致資源長時間未被釋放（如文件句柄未關閉）。
  • 手動調用 Dispose()：通過 Dispose() 可以立即釋放資源，確保資源的及時性。

(2) 與 using 語句的結合

  • using 語句：C# 提供了語法糖，確保 IDisposable 對象在作用域結束時自動調用 Dispose()。
    using (var file = new FileStream("data.txt", FileMode.Open))
{// 使用 file 進行操作
} // 自動調用 file.Dispose()
  • 異常安全：即使代碼塊內拋出異常，Dispose() 仍會被調用。

(3) 標準實現模式

  • 典型實現：需要處理資源釋放的類應實現 IDisposable，并遵循以下模式：
    public class ResourceHolder : IDisposable
{private bool _disposed = false;private IntPtr _handle; // 非托管資源public void Dispose(){Dispose(true);GC.SuppressFinalize(this); // 防止析構函數再次釋放}protected virtual void Dispose(bool disposing){if (!_disposed){if (disposing){// 釋放托管資源（如其他 IDisposable 對象）}// 釋放非托管資源（如 _handle）_disposed = true;}}~ResourceHolder() // 析構函數（Finalizer）{Dispose(false);}
}
    • 析構函數（Finalizer）：作為兜底，確保即使未顯式調用 Dispose()，資源也能在 GC 回收時釋放。
    • GC.SuppressFinalize(this)：避免重復調用析構函數。

(4) SafeHandle 的引入

  • 更安全的資源管理：.NET 2.0 引入了 SafeHandle（如 SafeFileHandle），它是 IDisposable 的子類，封裝了非托管資源的釋放邏輯，避免直接操作原始句柄。

4. 實際應用場景

(1) 常見實現 IDisposable 的類

  • 文件操作：FileStream、StreamReader、StreamWriter。
  • 網絡通信：HttpClient、TcpClient、Socket。
  • 數據庫連接：SqlConnection、SqlCommand。
  • 圖形資源：Bitmap、Brush。
  • 線程同步：Mutex、Semaphore。

(2) 使用 using 的典型示例

// 文件讀取
using (var reader = new StreamReader("example.txt"))
{string content = reader.ReadToEnd();
} // 自動關閉文件流// HTTP 請求
using (var client = new HttpClient())
{var response = await client.GetAsync("https://example.com");
} // 自動釋放網絡連接

5. 不實現 IDisposable 的后果

  • 資源泄漏：非托管資源未釋放，可能導致系統資源耗盡（如文件句柄泄漏導致無法打開新文件）。
  • 性能問題：資源未及時釋放，可能影響程序性能（如數據庫連接池耗盡）。
  • 不可預測的行為：GC 的不確定性可能導致程序行為不穩定。

6. 最佳實踐

  1. 實現 IDisposable 的類應遵循標準模式。
  2. 優先使用 using 語句管理資源。
  3. 避免在 finally 塊中手動調用 Dispose()（除非需要跨多個 try 塊）。
  4. 不要在析構函數中釋放托管資源（僅釋放非托管資源）。
  5. 使用 SafeHandle 替代原始句柄（更安全、更簡潔）。

7. 總結

特性說明
核心作用管理非托管資源，確保及時釋放
實現方式提供 Dispose() 方法，結合 using 語句或手動調用
與 GC 的關系補充 GC 的不足，顯式控制資源釋放
異常安全性using 語句確保資源釋放，即使發生異常
適用場景文件、網絡、數據庫、圖形資源等
標準實現模式包含析構函數、Dispose(bool) 和 GC.SuppressFinalize

通過正確使用 IDisposable 和 using 語句，可以顯著提升代碼的健壯性和資源管理效率！

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/web/96152.shtml
繁體地址，請注明出處：http://hk.pswp.cn/web/96152.shtml
英文地址，請注明出處：http://en.pswp.cn/web/96152.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

STM32HAL 快速入門（二十）：UART 中斷改進 —— 環形緩沖區解決數據丟失

STM32HAL 快速入門（二十）：UART 中斷改進 —— 環形緩沖區解決數據丟失

前言 大家好，這里是 Hello_Embed。上一篇我們用中斷方式實現了 UART 收發，但發現一個關鍵問題：若 CPU 在處理其他任務時未及時重新使能接收中斷，新數據會覆蓋舊數據，導致丟失。本篇的核心改進方案是 ——“中斷接收 環…
閱讀更多...
使用Docker搭建MaxKB智能體平臺

使用Docker搭建MaxKB智能體平臺

1、系統要求 詳見： https://maxkb.cn/docs/v2/quick_start https://maxkb.cn/docs/v2/installation/offline_installtion https://maxkb.cn/docs/v2/installation/online_installtion 2、安裝Docker 合集：Docker安裝與使用 3、安裝MaxKB 詳見&#xf…
閱讀更多...
寵物電商痛點破解：智能客服的關鍵作用

寵物電商痛點破解：智能客服的關鍵作用

在寵物電商蓬勃發展的當下，行業面臨著諸多痛點。從客戶咨詢的高頻率到訂單處理的復雜性，每一個環節都可能成為制約發展的瓶頸。而智能客服的出現，為這些痛點提供了有效的解決方案，成為寵物電商行業不可或缺的助力。一、寵物電商的…
閱讀更多...
基于GraphRAG+Ollama驗證知識圖譜和檢索增強融合

基于GraphRAG+Ollama驗證知識圖譜和檢索增強融合

之前介紹了知識圖譜與檢索增強的融合探索GraphRAG。 https://blog.csdn.net/liliang199/article/details/151189579 這里嘗試在CPU環境，基于GraphRAGOllama，驗證GraphRAG構建知識圖譜和檢索增強查詢過程。 1 環境安裝 1.1 GraphRAG安裝 在本地cpu環境…
閱讀更多...
36頁可編輯PPT | 某制造集團燈塔工廠解決方案

36頁可編輯PPT | 某制造集團燈塔工廠解決方案

制造業企業訂單種類多，傳統產線換型慢，庫存高，財務壓力大。工人年齡大，招工難，工資漲，效率低。海外對手用低價和柔性產線搶單，國內同行用數字化縮短交期。企業想擴產，又怕投資重、回…
閱讀更多...
Redis 非緩存核心場景及實例說明

Redis 非緩存核心場景及實例說明

Redis 非緩存核心場景及實例說明 一、分布式鎖 分布式鎖用于解決分布式系統中多節點競爭同一資源的問題，確保操作原子性。Redis 實現分布式鎖的核心思路是利用鍵的唯一性和原子命令，通常基于 Redisson 框架簡化實現（底層依賴 Redis 命令&…
閱讀更多...
【技術教程】如何將ONLYOFFICE文檔集成到使用Spring Boot框架編寫的Java Web應用程序中

【技術教程】如何將ONLYOFFICE文檔集成到使用Spring Boot框架編寫的Java Web應用程序中

在現代協作辦公環境中，將功能強大的文檔編輯器無縫集成到自有業務系統中，已成為提升工作效率和用戶體驗的關鍵需求。ONLYOFFICE 文檔服務器提供了一套成熟的在線文檔編輯解決方案，而 Java Spring Boot 則是構建高效、模塊化 Web 應用的熱門框…
閱讀更多...
openharmony之AV_CodeC音視頻編解碼模塊詳解(二)

openharmony之AV_CodeC音視頻編解碼模塊詳解(二)

1. 音頻解碼器函數調用流程 1.1 音頻解碼器架構概覽 decoder:解碼器 encoder:編碼器 前面文章介紹了關于openHarmony的AV_CodeC模塊，這篇文章將詳細講解編解碼時函數的調用流程 音頻解碼器采用插件化架構，核心實現位于： services/engine/codec/audio/decoder/audio_ffmpeg…
閱讀更多...
PDF24 Creator：免費的多功能PDF工具

PDF24 Creator：免費的多功能PDF工具

在處理PDF文件時，一個功能強大且免費的PDF工具是許多用戶的首選。PDF24 Creator作為一款免費的PDF工具，提供了豐富的功能，幫助用戶創建、編輯和轉換PDF文件，滿足從初學者到專業用戶的各種需求。它不僅支持PDF與Word、Excel等15種以…
閱讀更多...
VBA 中使用 ADODB 操作 SQLite 插入中文亂碼問題

VBA 中使用 ADODB 操作 SQLite 插入中文亂碼問題

問題 使用 VBA 的 ADODB 對象的 command 對象、parameter 對象，插入的中文數據為亂碼 驅動下載、安裝、引用 驅動網址(下載路徑) 使用的 ODBC 驅動（需要梯子才能下載，感謝大佬開源） http://www.ch-werner.de/sqliteodbc/ 版本…
閱讀更多...
執行select * from a where rownum＜1；，數據庫子進程崩潰，業務中斷。

執行select * from a where rownum＜1；，數據庫子進程崩潰，業務中斷。

文章目錄環境癥狀觸發條件解決方案環境 系統平臺&#xff1a;Linux x86-64 Red Hat Enterprise Linux 7 版本&#xff1a;4.5.2 癥狀 執行select * from a where rownum<1;&#xff0c;數據庫子進程崩潰&#xff0c;業務中斷。 觸發條件 select 和 where條件帶有rownum…
閱讀更多...
python庫 Py2app 的詳細使用（將 Python 腳本變為 MacOS 獨立軟件包）

python庫 Py2app 的詳細使用（將 Python 腳本變為 MacOS 獨立軟件包）

更多內容請見： python3案例和總結-專欄介紹和目錄 文章目錄 一、Py2app 概述 1.1 Py2app 介紹 1.2 安裝 1.3 替代工具推薦 二、基礎使用 2.1 最簡單的 setup.py 文件 2.2 完整示例 2.3 配置選項詳解 2.4 完整項目案例 2.5 打包為單文件應用（可選） 三、高級配置 3.1 處理特定…
閱讀更多...
NTP配置為客戶端廣播監聽模式

NTP配置為客戶端廣播監聽模式

前言 項目需求&#xff1a; 使能ntp為客戶端模式&#xff0c;能監服務端廣播模式發出的ntp報文&#xff0c;計算出服務端的時間與客戶端的時間偏差并上報。 開發狀況&#xff1a; 交叉編譯ntp源碼&#xff0c;將修改后的ntpd進程部署到設備上作為客戶端完成項目需求 如何操作&a…
閱讀更多...
Claude-Flow 使用指南

Claude-Flow 使用指南

Claude-Flow 不僅僅是一個工具&#xff0c;更是一個強大的AI驅動開發編排平臺。本問初步帶您深入了解 Claude-Flow v2.0.0 Alpha 的強大功能&#xff0c;助您在AI開發領域如虎添翼。1. 簡介&#xff1a;什么是 Claude-Flow&#xff1f; Claude-Flow v2 Alpha 是一個企業級的AI編…
閱讀更多...
系統梳理 Test-Time Compute 的主要實現路徑

系統梳理 Test-Time Compute 的主要實現路徑

編者按&#xff1a; AI 真的在“思考”嗎&#xff1f;當模型面對數學推理、代碼生成或復雜決策時&#xff0c;它是如何一步步推演出答案的&#xff1f;如果你曾困惑于大模型在關鍵任務中表現不穩定、缺乏可解釋性&#xff0c;甚至生成結果難以驗證&#xff0c;那么你并不孤單。…
閱讀更多...
vue 經常寫的echarts圖表模塊結構抽取

vue 經常寫的echarts圖表模塊結構抽取

vue 經常寫的echarts圖表模塊結構抽取將項目中經常寫的結構抽取一下, 方便以后用 表頭包含標題和右側操作部分下面為圖表 <div class"chartBox"><div class"chartheadbox"><div class"chartheadleft">這是圖表標題</div>…
閱讀更多...
主流的開源協議（MIT，Apache，GPL v2/v3）

主流的開源協議（MIT，Apache，GPL v2/v3）

文章目錄1. MIT 協議 (MIT License)2. Apache 2.0 協議 (Apache License 2.0)3. GPL v2 協議 (GNU General Public License v2)“開源協議選擇指南”的流程圖 flowchart TDA[開始選擇開源協議] --> B{是否要求修改后必須開源?<br>(是否具有 傳染性?)};B -- 是&…
閱讀更多...
CameraService筆記

CameraService筆記

cameraservicecamera 結構圖1. 啟動CameraServer1.1 注冊media.camera服務1.2 構造CameraService1.3 CameraService::onFirstRef1.4 CameraService::enumerateProviders&#xff1a;前置準備知識1.4 CameraService::enumerateProviders&#xff1a;Provider和Device初始化1.4.1…
閱讀更多...
MacOS 15.6 編譯SDL3 Android平臺多架構so庫

MacOS 15.6 編譯SDL3 Android平臺多架構so庫

成功編譯輸出： 編譯： Android平臺多架構編譯腳本： sdl3_android_build.sh #!/bin/bash# 設置變量 macos 其他系統需要更改路徑 SDL_SOURCE_DIR=$(pwd)/SDL BUILD_DIR=${SDL_SOURCE_DIR}/../sdl3_build_android NDK_PATH=$HOME/Library/Android/Sdk/Ndk/25.2.9519653 CMAKE…
閱讀更多...
Real-IAD D3: A Real-World 2D/Pseudo-3D/3D Dataset for Industrial Anomaly

Real-IAD D3: A Real-World 2D/Pseudo-3D/3D Dataset for Industrial Anomaly

Real-IAD D: A Real-World 2D/Pseudo-3D/3D Dataset for Industrial Anomaly Detection Paper Github 摘要 隨著工業異常檢測&#xff08;Industrial Anomaly Detection, IAD&#xff09;復雜程度的不斷提升&#xff0c;多模態檢測方法已成為機器視覺領域的研究焦點。然而&a…
閱讀更多...
最新文章

Copyright @ 2022~2023