C#的event关键字有什么作用？如何发布和订阅事件？-C#.Net教程-PHP中文网

C#中的event关键字提供类型安全的观察者模式实现，通过定义事件、触发事件和订阅事件实现对象间松耦合通信；使用event而非public delegate可确保封装性、防止外部触发和误操作；推荐使用EventHandler<TEventArgs>泛型委托和继承EventArgs的自定义参数类，并遵循命名规范；需注意内存泄漏、异常传播、执行顺序不确定及跨线程UI更新等潜在问题，合理取消订阅、处理异常并采用弱事件模式以提升健壮性和性能。

c#的event关键字有什么作用？如何发布和订阅事件？

C#中的

event

登录后复制

关键字提供了一种强大且类型安全的机制，用于实现观察者模式，让对象（发布者）能够通知其他对象（订阅者）某个特定事件的发生，而无需直接了解这些订阅者的具体信息。这就像一个广播系统：发布者发出信号，所有感兴趣的订阅者都能接收到并作出响应。发布事件涉及在发布者类中定义事件并适时触发它，而订阅事件则是在订阅者类中将方法（事件处理程序）附加到该事件上。

解决方案

要发布和订阅事件，你需要定义一个发布者类和一个或多个订阅者类。

发布者（Publisher）的实现：

定义一个委托（Delegate）： 委托定义了事件处理方法的签名。通常，我们会使用

EventHandler

登录后复制

或泛型的

EventHandler<TEventArgs>

登录后复制

。

// 假设我们要传递一个字符串消息
public class MessageEventArgs : EventArgs
{
    public string Message { get; }
    public MessageEventArgs(string message)
    {
        Message = message;
    }
}

public class Notifier
{
    // 声明一个事件，类型是EventHandler<MessageEventArgs>
    // 这表示事件处理方法需要接收一个object sender和MessageEventArgs e参数
    public event EventHandler<MessageEventArgs>? MessageSent;

    public void SendMessage(string msg)
    {
        Console.WriteLine($"Notifier: 准备发送消息 '{msg}'...");
        // 触发事件。在C# 6.0及以后，可以使用 ?.Invoke() 安全地调用
        // 传统方式是检查 MessageSent != null
        MessageSent?.Invoke(this, new MessageEventArgs(msg));
        Console.WriteLine("Notifier: 消息发送完成。");
    }
}

登录后复制

订阅者（Subscriber）的实现：

创建事件处理方法： 这个方法必须与发布者事件的委托签名匹配。
订阅事件： 使用
```
+=
```
登录后复制
运算符将事件处理方法附加到发布者的事件上。
取消订阅（可选但推荐）： 使用
```
-=
```
登录后复制
运算符在不再需要时移除事件处理方法，这对于避免内存泄漏很重要。

    public class Listener
    {
        private string _name;

        public Listener(string name)
        {
            _name = name;
        }

        // 事件处理方法，签名与EventHandler<MessageEventArgs>匹配
        public void OnMessageReceived(object? sender, MessageEventArgs e)
        {
            Console.WriteLine($"{_name}: 接收到来自 {((Notifier?)sender)?.GetType().Name ?? "未知来源"} 的消息：'{e.Message}'");
        }
    }

    // 示例用法
    public class Program
    {
        public static void Main(string[] args)
        {
            Notifier notifier = new Notifier();
            Listener listener1 = new Listener("监听者A");
            Listener listener2 = new Listener("监听者B");

            // 订阅事件
            notifier.MessageSent += listener1.OnMessageReceived;
            notifier.MessageSent += listener2.OnMessageReceived;

            notifier.SendMessage("你好，世界！");
            Console.WriteLine("
--- 监听者B取消订阅 ---
");

            // 监听者B取消订阅
            notifier.MessageSent -= listener2.OnMessageReceived;

            notifier.SendMessage("这是一条测试消息。");

            // 当程序结束或不再需要时，通常也建议取消订阅
            notifier.MessageSent -= listener1.OnMessageReceived;
        }
    }

登录后复制

运行上述代码，你会看到消息首先被两个监听者接收，在监听者B取消订阅后，只有监听者A会继续接收消息。

为什么应该使用

event

登录后复制

关键字而不是直接公开

delegate

登录后复制

字段？

这是一个非常关键的问题，也是

event

登录后复制

关键字存在的根本原因。如果只是简单地声明一个

public delegate MyDelegate MyEvent;

登录后复制

字段，确实也能实现类似的回调机制，但它会带来一些严重的封装性、健壮性和安全性问题。

event

登录后复制

关键字本质上是对一个委托字段的封装，它通过隐式地实现

add

登录后复制

和

remove

登录后复制

访问器，限制了外部代码对这个委托的直接操作：

封装性与安全性：
- 只允许
  +=
  登录后复制
  和
  -=
  登录后复制
  操作：
```
event
```
  登录后复制
  只允许外部代码使用
```
+=
```
  登录后复制
  （添加事件处理方法）和
```
-=
```
  登录后复制
  （移除事件处理方法）。你不能在类外部直接用
```
=
```
  登录后复制
  来赋值，这意味着你不能不小心地清空所有已注册的事件处理方法，或者替换掉已有的订阅者。
- 防止外部触发：
```
event
```
  登录后复制
  只能由其声明的类（或其派生类）内部来触发（Invoke）。外部代码无法直接调用事件，这保证了事件触发的控制权始终在发布者手中，防止了不必要的或恶意的事件触发。
- 对比
  public delegate
  登录后复制
  ：如果你直接公开一个
```
public delegate MyDelegate MyEvent;
```
  登录后复制
  ，外部代码可以随意执行
```
MyEvent = null;
```
  登录后复制
  （清空所有订阅者），
```
MyEvent = SomeMethod;
```
  登录后复制
  （覆盖所有订阅者），甚至
```
MyEvent.Invoke();
```
  登录后复制
  （在发布者不知情的情况下触发事件）。这完全破坏了事件的意图和封装性。
线程安全（针对订阅/取消订阅）：
- ```
event
```
  登录后复制
  的
```
add
```
  登录后复制
  和
```
remove
```
  登录后复制
  访问器在内部是线程安全的。这意味着在多线程环境下，多个线程同时尝试订阅或取消订阅同一个事件时，CLR会确保委托链的修改是原子性的，从而避免了潜在的竞态条件和损坏。
- 需要注意的是，这仅限于
```
add
```
  登录后复制
  和
```
remove
```
  登录后复制
  操作，事件的实际
```
Invoke
```
  登录后复制
  （触发）过程本身并不提供线程安全，如果事件处理程序修改共享状态，仍需手动处理线程同步。
清晰的意图表达：
- 使用
```
event
```
  登录后复制
  关键字明确地告诉代码读者：“这是一个事件，它遵循观察者模式，外部可以订阅，但不能随意操作或触发。”这比一个普通的
```
public delegate
```
  登录后复制
  字段更能清晰地表达设计意图。

所以，尽管

delegate

登录后复制

是事件的基础，但

event

登录后复制

关键字提供了必要的封装和保护，使得事件机制更加健壮、安全和易于管理，是实现事件驱动编程的最佳实践。

事件处理程序和事件参数的常见模式是什么？

在C#中，事件处理程序和事件参数的设计遵循一套约定俗成的模式，这不仅提高了代码的可读性，也方便了框架和库的互操作性。

标准事件委托
```
EventHandler
```
登录后复制
和
EventHandler<TEventArgs>
登录后复制
：

阿里云-虚拟数字人
阿里云-虚拟数字人是什么？ ...

2

查看详情
- public delegate void EventHandler(object? sender, EventArgs e);
  登录后复制
  这是最基本的事件委托，用于事件不传递任何特定数据的情况。
```
sender
```
  登录后复制
  参数通常是事件的发布者（即触发事件的对象），
```
e
```
  登录后复制
  参数是
```
EventArgs.Empty
```
  登录后复制
  。例如：
```
public event EventHandler? SomethingHappened;
```
  登录后复制
- public delegate void EventHandler<TEventArgs>(object? sender, TEventArgs e) where TEventArgs : EventArgs;
  登录后复制
  这是更常用、更灵活的泛型版本。当事件需要传递额外数据时，你应该使用它。
```
TEventArgs
```
  登录后复制
  必须是一个继承自
```
System.EventArgs
```
  登录后复制
  的类型。例如：
```
public event EventHandler<DataReceivedEventArgs>? DataReceived;
```
  登录后复制

自定义事件参数类（

TEventArgs

登录后复制

）：

当你需要向事件处理程序传递自定义数据时，必须创建一个继承自
```
System.EventArgs
```
登录后复制
的类。这个类应该包含所有你需要传递给订阅者的信息。
设计原则：
- 通常，事件参数类应该是不可变的（immutable），即属性只提供
```
get
```
  登录后复制
  访问器。这样可以避免事件处理程序在处理过程中意外修改参数，影响其他处理程序或发布者。
- 属性名应具有描述性。

示例：

// 假设我们有一个下载器，下载完成时需要传递文件路径和大小
public class DownloadCompletedEventArgs : EventArgs
{
    public string FilePath { get; }
    public long FileSize { get; }
    public DateTime CompletionTime { get; }

    public DownloadCompletedEventArgs(string filePath, long fileSize)
    {
        FilePath = filePath;
        FileSize = fileSize;
        CompletionTime = DateTime.Now;
    }
}

public class Downloader
{
    public event EventHandler<DownloadCompletedEventArgs>? DownloadCompleted;

    public void StartDownload(string url)
    {
        Console.WriteLine($"开始下载 {url}...");
        // 模拟下载过程
        System.Threading.Thread.Sleep(1000);
        string filePath = $"C:\Downloads\{Path.GetFileName(url)}";
        long fileSize = new Random().Next(1024 * 1024, 10 * 1024 * 1024); // 1MB to 10MB

        Console.WriteLine($"下载完成：{filePath}, 大小：{fileSize} 字节");
        DownloadCompleted?.Invoke(this, new DownloadCompletedEventArgs(filePath, fileSize));
    }
}

登录后复制

命名约定：
- 事件名： 通常是过去时态的动词，表示某个动作已经发生（例如
```
Click
```
  登录后复制
  ,
```
Loaded
```
  登录后复制
  ,
```
DownloadCompleted
```
  登录后复制
  ）。
- 事件处理方法名： 通常以
```
On
```
  登录后复制
  开头，后跟事件名（例如
```
OnButtonClick
```
  登录后复制
  ,
```
OnDataReceived
```
  登录后复制
  ）。
- 事件参数类名： 通常以事件名开头，以
```
EventArgs
```
  登录后复制
  结尾（例如
```
ClickEventArgs
```
  登录后复制
  ,
```
DataReceivedEventArgs
```
  登录后复制
  ）。
- 触发事件的方法名： 通常是
```
On
```
  登录后复制
  开头，后跟事件名，并标记为
```
protected virtual
```
  登录后复制
  ，以便派生类可以重写或扩展事件触发逻辑，同时在内部调用事件（例如
```
protected virtual void OnDownloadCompleted(DownloadCompletedEventArgs e)
```
  登录后复制
  ）。

遵循这些模式，不仅能让你的代码更符合C#社区的习惯，也使得事件机制的使用更加清晰、一致和易于维护。

使用事件时有哪些性能考虑或潜在陷阱？

事件机制虽然强大，但在不恰当的使用下，确实可能引入一些性能问题或难以调试的逻辑错误。理解这些潜在的陷阱对于编写健壮、高效的C#代码至关重要。

内存泄漏（Memory Leaks）——最常见的陷阱：
- 问题描述： 当一个订阅者对象订阅了发布者的事件，但没有在适当的时候取消订阅（使用
```
-=
```
  登录后复制
  ），即使订阅者对象本身已经不再被使用，发布者仍然会持有对它的引用。只要发布者对象存在，垃圾回收器就无法回收订阅者对象，从而导致内存泄漏。这在订阅者生命周期短于发布者的情况下尤为突出。
- 场景举例： 一个全局性的日志服务（发布者）被多个临时创建的UI组件（订阅者）订阅。如果UI组件在关闭时没有取消订阅，日志服务会一直持有对这些已关闭UI组件的引用，导致它们无法被回收。
- 解决方案：
  - 明确取消订阅： 在订阅者不再需要接收事件时，务必调用
```
-=
```
    登录后复制
    操作符取消订阅。例如，在UI组件的
```
Dispose
```
    登录后复制
    方法或窗体关闭事件中执行取消订阅。
  - 弱事件模式（Weak Events）： 对于生命周期不确定的订阅者，或者为了避免手动取消订阅的繁琐和遗漏，可以使用弱事件模式。这通常通过
```
WeakEventManager
```
    登录后复制
    （WPF/Silverlight提供）或自定义实现来完成，它允许发布者持有订阅者的弱引用，不阻止垃圾回收。
  - 事件生命周期管理： 确保事件的订阅和取消订阅与对象的生命周期同步。
事件处理程序的执行顺序不确定性：
- 问题描述： C#规范并未明确保证事件处理程序被调用的顺序。虽然在大多数情况下，它们会按照订阅的顺序被调用，但你不应该依赖这种行为。
- 解决方案： 避免编写依赖于特定事件处理程序执行顺序的代码。如果存在顺序依赖，考虑重新设计，例如使用责任链模式，或者让一个中央协调器来管理多个操作的执行。

异常处理——一个处理程序失败可能影响所有：

问题描述： 当事件被触发时，如果某个订阅者的事件处理程序抛出了未捕获的异常，这个异常会向上冒泡，可能会导致整个应用程序崩溃，或者至少阻止后续的事件处理程序被调用。

解决方案：

在事件触发处捕获异常： 在发布者触发事件的代码中，遍历委托链并为每个处理程序调用都加上
```
try-catch
```
登录后复制
块。这样即使某个处理程序失败，其他处理程序仍能正常执行，并且可以记录下异常信息。

示例：

protected virtual void OnDownloadCompleted(DownloadCompletedEventArgs e)
{
    // 获取委托链的副本，防止在遍历过程中被修改
    EventHandler<DownloadCompletedEventArgs>? handler = DownloadCompleted;
    if (handler != null)
    {
        // 获取所有订阅者
        Delegate[] delegates = handler.GetInvocationList();
        foreach (EventHandler<DownloadCompletedEventArgs> del in delegates)
        {
            try
            {
                del.Invoke(this, e);
            }
            catch (Exception ex)
            {
                // 记录异常，但允许其他处理程序继续执行
                Console.Error.WriteLine($"错误：事件处理程序 {del.Method.Name} 抛出异常: {ex.Message}");
                // 考虑是否需要重新抛出异常，或者根据业务逻辑决定
            }
        }
    }
}

登录后复制

订阅者内部处理： 订阅者也可以在自己的事件处理程序内部进行异常处理，但这仅限于处理自身逻辑的异常，无法阻止其他处理程序因异常而中断。

性能开销（相对较小但存在）：
- 问题描述： 虽然通常可以忽略不计，但在事件触发非常频繁（例如，每秒数千次）且有大量订阅者的情况下，事件的
```
Invoke
```
  登录后复制
  操作会带来一些开销。这包括委托的创建、参数的封装、以及遍历委托链并调用每个方法的开销。
- 解决方案：
  - 避免过度频繁触发： 如果事件触发频率极高，考虑是否能降低频率，或者批量处理事件。
  - 减少不必要的订阅： 确保只有真正需要接收事件的对象才进行订阅。
  - 考虑其他模式： 对于高性能场景，有时可能需要考虑更底层的回调机制或专门的消息队列。
跨线程调用UI更新：
- 问题描述： 如果事件发布者在非UI线程上触发事件，而事件处理程序试图直接更新UI（例如WinForms或WPF控件），则会导致跨线程访问UI的异常。UI元素通常只能在其创建的线程上被访问。
- 解决方案：
  - 使用
    Invoke
    登录后复制
    或
    BeginInvoke
    登录后复制
    ：在WinForms中，使用控件的
```
Invoke
```
    登录后复制
    或
```
BeginInvoke
```
    登录后复制
    方法将UI更新操作调度回UI线程。
  - 使用
    Dispatcher
    登录后复制
    ：在WPF中，使用
```
Application.Current.Dispatcher.Invoke
```
    登录后复制
    或
```
BeginInvoke
```
    登录后复制
    。
  - 异步/等待模式： 在现代C#中，结合
```
async/await
```
    登录后复制
    可以更优雅地处理跨线程UI更新。