Lazy<T>与后备字段实现延迟初始化的差异、性能及内存对比咨询

咱们先把这两种实现的核心区别捋清楚，顺带先提个关键问题：你给出的Lazy<T>代码写法有个小bug——用表达式体属性（=>）每次访问Products都会创建新的Lazy<T>实例，导致每次调用Products.Value都会重新执行数据库查询，完全失去了延迟初始化只执行一次的意义。正确的写法应该把Lazy<T>作为私有字段初始化，比如：

class Category {
    public int CategoryID { get; set; }
    public string CategoryName { get; set; }
    // 用私有字段存储Lazy实例，确保只创建一次
    private readonly Lazy<ICollection<Product>> _lazyProducts;

    public Category() {
        _lazyProducts = new Lazy<ICollection<Product>>(() => GetProductsByCategoryID(this.CategoryID));
    }

    // 对外暴露的属性直接返回Lazy的Value
    public ICollection<Product> Products => _lazyProducts.Value;

    public ICollection<Product> GetProductsByCategoryID(int categoryID) {
        // 从数据库获取Products
    }
}

下面基于这个正确的Lazy<T>实现，对比两种方案的差异：

一、核心差异 #

1. 线程安全性 #

• 后备字段实现：默认是非线程安全的。如果多个线程同时首次访问Products，会同时进入if (products == null)分支，导致多次执行数据库查询，甚至可能出现products被多次赋值的情况。要解决这个问题，你得手动加锁（比如lock语句），但会增加代码复杂度。
• Lazy实现：默认采用LazyThreadSafetyMode.ExecutionAndPublication模式，内部已经处理了线程同步，确保多线程下初始化逻辑只执行一次，不需要你手动写锁，代码更简洁健壮。

2. 初始化逻辑的执行次数 #

• 后备字段实现：只要products字段为null，每次访问Products都会触发初始化。如果有内部逻辑不小心把products设为null，会再次执行数据库查询。
• Lazy实现：初始化逻辑（GetProductsByCategoryID）绝对只会执行一次，无论被访问多少次，哪怕集合内容被修改，初始化过程也不会重复。

3. 代码封装性 #

• 后备字段实现：初始化逻辑直接写在属性getter里，和属性访问逻辑混在一起，逻辑复杂时会让getter变得臃肿，代码耦合度高。
• Lazy实现：初始化逻辑被封装到独立的GetProductsByCategoryID方法中，Lazy<T>只负责管理初始化时机和线程安全，职责单一，代码更清晰易维护。

二、性能与内存对比 #

性能方面 #

• 单线程场景：两种实现性能差异极小，都是首次访问触发初始化，之后直接返回缓存结果。Lazy<T>因为内部有线程安全检查，会有一点点可以忽略的微小开销，在普通业务场景下完全感知不到。
• 多线程场景：Lazy<T>的默认线程安全实现比手动加锁的后备字段更高效（它内部用了优化的双重检查锁定机制），而不加锁的后备字段会有重复查询数据库的性能损耗，甚至数据不一致。

内存方面 #

• 后备字段实现：Category对象创建后，products字段是null，内存开销就是对象本身的几个字段（CategoryID、CategoryName、一个引用），非常小。
• Lazy实现：Category对象创建时会持有一个Lazy<T>实例的引用，这个实例本身会占用几十字节的额外内存（用来存储初始化状态、委托等），但和集合本身的内存相比完全可以忽略。除非你创建了百万级别的Category对象，这点额外开销才会累积，但这种场景极其罕见。

总结 #

• 如果是单线程环境、初始化逻辑简单，后备字段实现足够用，代码也简洁。
• 如果是多线程环境，或者希望代码更健壮、初始化逻辑封装更清晰，优先用Lazy<T>，它帮你省了手动处理线程安全的麻烦，代码可读性也更好。

内容的提问来源于stack exchange，提问作者Kinin Roza