博客 / 列表

Rick Carter - 死鎖是怎麼發生的，舉個簡單的例子

死鎖的示例 下面就是一個會死鎖的示例代碼： // 異步死鎖示例 - 不使用 TaskScheduler，僅用多個 Task 互相等待 Console.WriteLine("=== 多 Task 互相等待死鎖 ===\n"); // 兩個任務互相用 .Result 等待對方完成 → 死鎖 var tcsA = new TaskCompletionSourceint(); var tcsB = n

.net , 後端

Rick Carter - hangfire內部執行器是同步的，會導致死鎖

再次遇到dotnet的第三方組件問題，就是hangfire的CoreBackgroundJobPerformer會導致死鎖，它是作為hagnfire服務端的job執行器的，它非常的關鍵，是job能夠運行的關鍵，這些庫可能讀是從很早的dotnetfremework時代移植過來的（我猜測的），同樣的存在同步調用異步代碼的問題，會導致死鎖。 它有問題的代碼如下： namespace Hangfire.S

.net , 後端

Rick Carter - 緩存讀寫代碼邏輯的正確姿勢

緩存通常用於提高數據訪問的效率。一般來説，緩存讀取和寫入的邏輯遵循“先從緩存取，取不到再從數據庫獲取並寫回緩存”的原則。為了避免多個線程同時修改緩存數據，我們需要加鎖來保證數據一致性。 邏輯概述 讀取緩存：緩存命中直接返回。 緩存未命中：加鎖，然後再次讀取緩存，緩存命中直接返回。 緩存還是未命中：執行數據庫查詢並更新緩存。 返回數據。 代碼大致這樣寫 public class Cach

.net , 後端

Rick Carter - dotnet未捕獲異常導致系統崩潰問題

一般情況下我們業務代碼不需要自己捕獲異常，因為目前我們常用框架都會自行處理異常，但是有些情況下需要自己處理異常，否則未處理的異常拋出會導致程序崩潰退出。 1.全局異常捕獲 // 1. AppDomain 未處理異常 AppDomain.CurrentDomain.UnhandledException += (sender, e) = { var exception = e.Exceptio

.net , 後端

Rick Carter - dotnet-dump安裝、收集dump和崩潰自動收集dump

繼續寫點基礎的東西，因為基礎的東西能帶新手入門，入門後的事情其實是比較簡單的。 我們開發dotnet程序後運行時經常出問題，比如cpu高、內存高、崩潰等問題，分析的方法就是使用dotnet的那套分析工具，今天以dotnet-dump為例，簡單説下從安裝到收集的操作步驟。 1.安裝SDK dotnet分析工具需要dotnet sdk環境，所以需要先安裝sdk，以docker下Debian系統為例。參

.net , 後端

Rick Carter - EFCore中巧妙利用ToQueryString()實現批插（不借助第三方包）

dotnet10發佈了，ef10也快發佈了，但是還是隻有批量更新（ExecuteUpdateAsync）和批量刪除（ExecuteDeleteAsync）功能，沒有批量插入。 今天給個辦法，在不引用第三方庫的情況下，巧妙利用ToQueryString()實現批插。 道理很簡單，就是用efcore的ToQueryString()方法返回sql字符串，然後替換拼接實現insert into(..

.net , 後端

Rick Carter - 修復達夢EFCore驅動布爾類型兼容問題

dm庫相比其他庫本身缺少一些語法差異，也可以説是缺陷。 比如： 0和1無法直接在sql中當作真假值用，where 0這種寫法不支持，報錯：查詢使用值表達式作為過濾條件； t.field is null 也無法直接作為select項； 不支持OUTER APPLY等SQL語法； 以及數據庫函數中的又只能用0和1作為布爾參數值。 但是dm.efcore生成的語句就是這樣的

.net , 後端

Rick Carter - dotnet使用redis時需要注意的問題

1.性能問題-批量多次讀寫、序列化和反序列化的場景 注意看到dotnet下的IDistributedCache接口內部方法聲明都是針對單個key的，當需要多次大量讀寫同一類型kv值時，存在多次連接redis的情況，導致性能特別慢。 在abp框架中AbpRedisCache有些SetMany和GetMany的方法，它可以很好的解決這個問題。 今天再分享一個Redis的批操作的寫法(db.

.net , 後端