博客 (50)

1. 临界区与 lock 关键字

   核心作用：
   

   通过将多线程访问串行化，保护共享资源或代码段。lock 关键字是 Monitor 类的语法糖，提供异常安全的临界区实现。

   实现示例：

   // 创建私有静态只读对象
   // private static readonly object _lockObj = new object();
   private static readonly System.Threading.Lock _locker = new(); // .NET 9+ 推荐使用 Lock 类型，避免传统 object 的性能损耗
   
   public void ThreadSafeMethod()
   {
       lock (_lockObj) 
       {
           // 临界区代码（每次仅一个线程可进入）
       }
   }

   超时机制：

   高并发场景可结合 Monitor.TryEnter 设置超时，避免无限等待：

   
   

   if (Monitor.TryEnter(lockObject, TimeSpan.FromSeconds(1)))
   {
       try { /* 操作 */ }
       finally { Monitor.Exit(lockObject); }
   }

   关键特性：

   用户态锁（无内核切换开销）

   自动调用Monitor.Enter和Monitor.Exit

   必须使用专用私有对象作为锁标识

   注意事项：

   ❌ 避免锁定this、Type实例或字符串（易引发死锁）

   ❌ 避免嵌套锁（需严格按顺序释放）

   ✅ 推荐readonly修饰锁对象

   ❌ lock 不适用于异步代码（async/await），需使用 SemaphoreSlim 实现异步锁

   lock 示例

    

2. 互斥锁（Mutex）

   核心作用：

   系统级内核锁，支持跨进程同步，但性能开销较高（用户态/内核态切换）。

   实现示例：

   using var mutex = new Mutex(false, "Global\\MyAppMutex");
   
   try 
   {
       // 等待锁（最大等待时间500ms）
       if (mutex.WaitOne(500)) 
       {
           // 临界区代码
       }
   }
   finally 
   {
       if (mutex != null)
       {
           mutex.ReleaseMutex();
       }
   }

   关键特性：

   支持跨应用程序域同步

   线程终止时自动释放锁

   支持命名互斥体（系统全局可见）

   适用场景：

   单实例应用程序控制

   进程间共享文件访问

   硬件设备独占访问

   Mutex 示例

    

3. 信号量（Semaphore）

   核心作用：

   通过许可计数器控制并发线程数，SemaphoreSlim为轻量级版本（用户态实现）。

   实现对比：

   类型	跨进程	性能	最大许可数
   Semaphore	✔️	低	系统限制
   SemaphoreSlim	❌	高	Int32.Max

   代码示例：

   // 创建初始3许可、最大5许可的信号量
   var semaphore = new SemaphoreSlim(3, 5);
   
   semaphore.Wait();  // 获取许可
   try 
   {
       // 资源访问代码
   }
   finally 
   {
       semaphore.Release();
   }

   异步编程

   private readonly SemaphoreSlim _asyncLock = new(1, 1);
   public async Task UpdateAsync()
   {
       await _asyncLock.WaitAsync();
       try { /* 异步操作 */ }
       finally { _asyncLock.Release(); }
   }

   典型应用：

   数据库连接池（限制最大连接数）

   API 请求限流

   批量任务并发控制

   Semaphore 示例

    
   

4. 事件（Event）

   核心机制：

   通过信号机制实现线程间通知，分为两种类型：

   类型	信号重置方式	唤醒线程数
   AutoResetEvent	自动	单个
   ManualResetEvent	手动	所有

   使用示例：

   var autoEvent = new AutoResetEvent(false);
   
   // 等待线程
   Task.Run(() => 
   {
       autoEvent.WaitOne();
       // 收到信号后执行
   });
   
   // 信号发送线程
   autoEvent.Set();  // 唤醒一个等待线程

   高级用法：

   配合WaitHandle.WaitAll实现多事件等待

   使用ManualResetEventSlim提升性能

   AutoResetEvent 示例

    
   

5. 读写锁（ReaderWriterLockSlim）

   核心优势：

   实现读写分离的并发策略，适合读多写少场景（如缓存系统）。

   锁模式对比：

   模式	并发性	升级支持
   读模式(EnterReadLock)	多线程并发读	❌
   写模式(EnterWriteLock)	独占访问	❌
   可升级模式	单线程读→写	✔️

   代码示例：

   var rwLock = new ReaderWriterLockSlim();
   
   // 读操作
   rwLock.EnterReadLock();
   try 
   {
       // 只读访问
   }
   finally 
   {
       rwLock.ExitReadLock();
   }
   
   // 写操作
   rwLock.EnterWriteLock();
   try 
   {
       // 排他写入
   }
   finally 
   {
       rwLock.ExitWriteLock();
   }

   最佳实践：

   优先使用ReaderWriterLockSlim（旧版有死锁风险）

   避免长时间持有读锁（可能饿死写线程）

   ReaderWriterLockSlim 示例
   

6. 原子操作（Interlocked）

   原理：

   通过CPU指令实现无锁线程安全操作。

   常用方法：

   int counter = 0;
   Interlocked.Increment(ref counter);      // 原子递增
   Interlocked.Decrement(ref counter);      // 原子递减
   Interlocked.CompareExchange(ref value, newVal, oldVal);  // CAS操作

   适用场景：

   简单计数器

   标志位状态切换

   无锁数据结构实现

    

7. 自旋锁（SpinLock）

   核心特点：

   通过忙等待（busy-wait）避免上下文切换，适用极短临界区（<1微秒）。

   实现示例：

   private SpinLock _spinLock = new SpinLock();
   
   public void CriticalOperation()
   {
       bool lockTaken = false;
       try 
       {
           _spinLock.Enter(ref lockTaken);
           // 极短临界区代码
       }
       finally 
       {
           if (lockTaken) _spinLock.Exit();
       }
   }

   优化技巧：

   单核CPU需调用Thread.SpinWait或Thread.Yield

   配合SpinWait结构实现自适应等待

    

8. 同步机制对比指南

   机制	跨进程	开销级别	最佳适用场景
   lock	❌	低	通用临界区保护
   Mutex	✔️	高	进程间资源独占
   Semaphore	✔️	中	并发数限制（跨进程）
   SemaphoreSlim	❌	低	并发数限制（进程内）
   ReaderWriterLockSlim	❌	中	读多写少场景
   SpinLock	❌	极低	纳秒级临界区
   Interlocked	-	无锁	简单原子操作

选择原则：

1. 优先考虑用户态锁（lock/SpinLock/SemaphoreSlim）

2. 跨进程需求必须使用内核对象（Mutex/Semaphore）

3. 读写比例超过10:1时考虑读写锁

4. 自旋锁仅用于高频短操作（如链表指针修改）

通过以上结构化的分类和对比，开发者可以更精准地选择适合特定场景的线程同步方案。建议在实际使用中配合性能分析工具（如BenchmarkDotNet）进行量化验证。

💡 ASP.NET 的异步编程（async/await）本质是单进程内的线程调度，不算“跨进程”。每个 IIS 应用程序池对应一个独立的工作进程（w3wp.exe），不同用户访问同一应用程序池下的 ASP.NET 网站，两者的请求均由同一个 w3wp.exe 进程处理。可能跨进程的场景有：Web Garden 配置、多应用程序池部署等。

在 C# 中，除了常规锁机制（如 lock、Mutex、Semaphore 等），还有一些内置类型通过内部锁或无锁设计实现线程安全。以下是常见的几类：

1. 线程安全集合（System.Collections.Concurrent）这些集合通过细粒度锁或无锁算法（如 CAS）实现线程安全，适合高并发场景。

• ConcurrentDictionary：分段锁机制，将数据分片存储，每个分片独立加锁，减少锁竞争。

• ConcurrentQueue / ConcurrentStack：基于原子操作（Interlocked）保证线程安全。

• ConcurrentBag：每个线程维护本地存储，减少争用，适合频繁添加和移除的场景。

• BlockingCollection：基于 ConcurrentQueue 和信号量（SemaphoreSlim）实现生产-消费者模式，支持阻塞和超时。

2. 不可变集合（System.Collections.Immutable） 通过数据不可变性实现线程安全（无需锁），每次修改返回新对象。

3. Lazy 的线程安全初始化（Lazy<T>） 通过锁或 Interlocked 确保延迟初始化的线程安全。

4. 通道（System.Threading.Channels）用于异步生产-消费者模型，内部通过锁和信号量管理容量限制。

5. 内存缓存（System.Runtime.Caching.MemoryCache）内部使用锁保护共享状态，确保线程安全。

6. 原子操作类型（Interlocked 类、Volatile 关键字、Unsafe 类）通过 CPU 指令实现无锁线程安全。

7. 其他同步工具（Barrier、CountdownEvent）虽然不是严格意义上的锁，但用于协调线程。

关键选择原则

• 兼容旧代码 → HttpUtility.UrlEncode 或 WebUtility.UrlEncode。

• 严格 URI 规范 → Uri.EscapeDataString 或 UrlEncoder。

• ASP.NET Core → UrlEncoder。

• 非 Web 或跨平台 → 弃用 System.Web，选择 System.Net 或 System.Text.Encodings.Web 中的方法。

通常，我们在更新一条数据库记录时，EF 先取出这一条记录：

var log = DbContext.MyTable.Find(id);

然后赋值字段并保存：

log.Result = "OK";
DbContext.SaveChanges();

这样就会产生两次数据库查询。

我们尝试用 Attach 方法。

先创建一个仅包含主键的对象：

var log  = new MyTable { Id = id };

将对象附加到上下文：

DbContext.MyTable.Attach(log);

然后更新需要更新的字段：

log.Result = "OK";
DbContext.SaveChanges();

这样，能在保留其它字段值的前提下，减少一次数据库查询。

但是需要注意的是：

当某非 null 字段需要恢复默认值时，EF 会忽略这个更改。（可能会因 EF 版本等原因有不同的结论）

举个例子：

某记录有个 int 型字段 a，在数据库中这个记录的 a 的值为 1，但 C# 中 int 型的默认值为 0，所以当 Attach 附加这个对象后，如果重新设置 log.a 为 0，那么保存后 a 的值仍为 1。

还有一种写法，利用 ExecuteUpdate 方法：

var affectedRows = DbContext.MyTable
  .Where(c => c.Id == id)
  .ExecuteUpdate(setters => setters
    .SetProperty(c => c.Result, "OK")
  );

返回匹配的行数。

这种写法不会遇到“恢复为默认值不生效”的问题，推荐使用。

截止 2024 年 9 月，CZDB 数据已支持 JAVA、PHP、C、Node.js、Python 语言解析，但官方迟迟未推出 C# / ASP.NET 的版本，于是我参照前面几种语言版本写了 C# 版，支持 IPv4 与 IPv6，实测查询速度，CZDB 版的 MEMORY 模式比原来的 DAT 版数据库快数百倍（具体要看磁盘和内存的读写速度）。能够有效降低 CPU 的使用率，特别是在需要频繁查询 IP 属地的应用场景（譬如每个 HTTP 请求都要判断 IP 属地来决定是否允许访问）。

我要试试→

源代码已提交给纯真官方，相信很快就会有官方版本的 SDK。

实例化方法一：DbSearcher(String dbFile, QueryType queryType, String key)

实例化方法二：DbSearcher(InputStream is, QueryType queryType, String key)

• 方法一通过传入文件路径来实例化，方法二通过传入文件流来实例化；

• 当 queryType 为 MEMORY 时，方法一和方法二只有在实例化时有性能差别，差别在于将指定路径的文件读到内存中保存；在执行 Search 方法时无性能差别，因为都是在内存中执行查找；

• queryType 为 MEMORY 和 BTREE 的差别在于前者是在内存中查找，速度快但占内存，后者是在文件中查找，速度慢但省内存。

错误：Padding is invalid and cannot be removed.

原因：可能是数据库文件与密钥不一致。

unpack("C*", $data)

C 表示一个无符号的字符（unsigned char），它将被解析为一个介于 0 到 255 之间的十进制整数。

* 表示重复该指令直到数据被完全解析。

对应到 C# 中，即在 VS 中断点调试看到的 data 的值。

未能找到路径“\roslyn\csc.exe”的一部分。

解决方法：

在 nuget 中直接卸载 Microsoft.CodeDom.Providers.DotNetCompilerPlatform

如果 web.config 报错，删除与 Microsoft.CodeDom.Providers.DotNetCompilerPlatform 相关的项，如：

<system.codedom>
	<compilers>
		<compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701;612;618" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
		<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008,40000,40008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
	</compilers>
</system.codedom>

然后遇到错误：

功能 空传播运算符 在 C# 5 中不可用。请使用 6 或更高的语言版本

所以还是少不了 Microsoft.CodeDom.Providers.DotNetCompilerPlatform

又把这货装上了，竟然不报错了。

这期间我更改过在 Release 模式下调试，将 .NET Framework 4.8 升级到 .NET Framework 4.8.1 等，然后又退回到原来的状态和版本，竟然都正常了。

就这样吧！

本文由 ChatGTP 3.5 提供

在 .NET C# 桌面应用程序中，你可以使用委托和事件来实现在窗体页面处理事务过程中实时更新界面。下面是一个示例，展示了在不同情况下如何更新主界面：

首先，在窗体页面中定义一个委托和一个事件，用于更新界面：

public delegate void UpdateUIHandler(string msg);
public event UpdateUIHandler UpdateUIEvent;

然后，在窗体的构造函数中订阅事件，并在事件处理程序中更新界面：

public Form1()
{
    InitializeComponent();
    UpdateUIEvent += UpdateUI;
}

private void UpdateUI(string msg)
{
    if (InvokeRequired)
    {
        Invoke(new UpdateUIHandler(UpdateUI), msg);
    }
    else
    {
        // 在这里更新界面
        label1.Text = msg;
    }
}

现在，你可以在窗体页面的任何地方调用 UpdateUIEvent 来触发更新界面的事件。例如，在按钮点击事件中：

private void button1_Click(object sender, EventArgs e)
{
    // 处理事务过程中实时更新界面
    string msg = "处理事务中...";
    UpdateUIEvent?.Invoke(msg);

    // 异步调用一个类方法中的方法，并在方法内部实时更新主界面
    Task.Run(() =>
    {
        MyClass myClass = new MyClass();
        myClass.LongRunningMethod(UpdateUIEvent);
    });
}

在上面的示例中，MyClass 是一个自定义的类，其中的 LongRunningMethod 是一个耗时的方法。在这个方法内部，你可以通过传递 UpdateUIEvent 来实时更新主界面：

public class MyClass
{
    public void LongRunningMethod(UpdateUIHandler updateUI)
    {
        // 处理事务过程中实时更新界面
        string msg = "处理事务中...";
        updateUI?.Invoke(msg);

        // 其他耗时操作...
    }
}

通过以上示例，你可以在窗体页面处理事务过程中实时更新界面，并且在异步调用的方法内部也能实时更新主界面。记得在更新界面时使用 Invoke 方法，以确保在主线程上更新界面，避免跨线程访问 UI 的问题。

客户端：Failed to connect to host.

服务端：无任何日志

原因：可能是域名、IP 或端口有误，或端口未开放。

客户端/服务端：530 Login incorrect.

原因：用户名或密码错误。

客户端/服务端：503 Use AUTH first.

原因：服务端开启了 FTPS 协议（FTP over TLS），且禁止了 FTP 协议（plain FTP）。

解决方法：不建议服务端恢复不安全的 FTP 协议，客户端应配置 client.Config 的 EncryptionMode、DataConnectionEncryption、SslProtocols、ValidateCertificate 等参数。

客户端/服务端：530 This server does not allow plain FTP. You have to use FTP over TLS.

原因：服务端启用了 FTPS。

解决方法：给 client.Config.EncryptionMode 正确的赋值（FtpEncryptionMode.Explicit 或 FtpEncryptionMode.Auto）。

服务端：[Error] TLS session of data connection not resumed.

原因：证书版本有误。

解决方法：给 client.Config.SslProtocols 赋值正确的 TLS 版本。

服务端：521 PROT P required

原因：服务端开启了“Require TLS session resumption on data connection when using PROT P”

解决方法：client.Config.DataConnectionEncryption = true;

客户端/服务端：450 TLS session of data connection has not resumed or the session does not match the control connection

原因：TLS 与控制连接不匹配，即服务端开启了“Require TLS session resumption on data connection when using PROT P”

解决方法：我暂时还不知道原因，临时关闭了“Require TLS session resumption on data connection when using PROT P”（不建议）。该问题出现在 FileZilla Server 0.x 版本，在 1.x 版本中没有该配置选项。

语言集成查询（LINQ）为 C# 和 VB 提供语言级查询功能和高阶函数 API，让你能够编写具有很高表达力度的声明性代码。

LINQ 有两种写法：查询语法和方法语法，查询语法又称查询表达式语法。

查询语法：

from 变量名 in 集合 where 条件 select 结果变量

方法语法：

集合.Where(变量名 => 条件)

LINQ 的标准查询运算符及语法示例

cats.Select(cat => cat.color)

from cat in cats
select cat.color

families.SelectMany(family => family.members
.Select(member => member.name))

from family in families
from member in family.members
select member.name

cats.Where(cat => cat.color == "white")

from cat in cats
where cat.color == "white"
select cat

cats.OrderBy(cat => cat.age)

from cat in cats
order by cat.age
select cat

cats.Reverse()

families.Join(
    members,
    family => family.familyId,
    member => member.familyId,
    (family, member) => new
    {
        family.familyId,
        member.name,
    })

families.GroupJoin(
    members,
    family => family.familyId,
    member => member.familyId,
    (family, familyMembers) => new
    {
        family.familyId,
        name = familyMembers.FirstOrDefault()?.name
    })

from family in families
join member in members on family.familyId equals member.familyId
select new
{
    family.familyId,
    member.name,
}

from family in families
join member in members on family.familyId equals member.familyId into g
from member in g.DefaultIfEmpty()
select new
{
    family.familyId,
    name = member?.name,
}

了解立即执行与延迟执行可以大大改善性能。