注册表模式（Registry）：从全局服务定位到Spring BeanFactory

说实话，注册表模式这个名字听起来挺唬人的。我第一次接触它是在一个老旧的EJB项目中，当时看到一堆JNDI查找代码，心里直犯嘀咕：这不就是个全局Map吗？后来我才明白，事情没那么简单。

注册表模式，说白了就是提供一个全局的、统一的服务定位机制。它让对象能够通过一个中央注册表来获取依赖，而不是自己创建或者硬编码引用。嗯，这其实就是“控制反转”思想的雏形。

为什么需要注册表？

你想想看，在大型系统中，对象之间的依赖关系有多复杂？A依赖B，B依赖C，C又依赖D...如果每个对象都自己去new依赖，那代码就成了一团乱麻。我在一个金融项目中就遇到过这种问题——一个交易引擎的初始化代码长达2000行，全是new来new去，改一个地方就要改一片。

注册表模式的核心价值在于：

• 解耦：调用者不需要知道具体实现类
• 集中管理：所有服务实例的创建和生命周期都在一个地方
• 延迟加载：可以按需创建对象，而不是启动时全部初始化
• 替换灵活：换一个实现只需要改注册表配置

注册表的核心结构

一个标准的注册表模式包含三个角色：

• 注册表接口：定义注册和查找的契约
• 具体注册表：实现存储和检索逻辑
• 查找机制：客户端如何从注册表获取服务

代码示例：从零实现注册表

我们先看一个Java版本的简单实现。我个人习惯先定义接口，再写实现，这样扩展起来方便。

// 注册表接口
public interface Registry {
    <T> void register(Class<T> type, T instance);
    <T> T lookup(Class<T> type);
    <T> void unregister(Class<T> type);
}

// 具体注册表实现
public class DefaultRegistry implements Registry {
    private final Map<Class<?>, Object> container = new ConcurrentHashMap<>();
    
    @Override
    public <T> void register(Class<T> type, T instance) {
        Objects.requireNonNull(type, "Type must not be null");
        Objects.requireNonNull(instance, "Instance must not be null");
        container.put(type, instance);
    }
    
    @Override
    @SuppressWarnings("unchecked")
    public <T> T lookup(Class<T> type) {
        Object instance = container.get(type);
        if (instance == null) {
            throw new IllegalStateException("No instance registered for: " + type.getName());
        }
        return (T) instance;
    }
    
    @Override
    public <T> void unregister(Class<T> type) {
        container.remove(type);
    }
}

这段代码看起来简单，但有几个坑要注意。我曾经在生产环境中遇到过一个问题——多线程并发注册导致数据不一致。所以这里用了ConcurrentHashMap，而不是普通的HashMap。

C++版本实现

C++的实现稍微复杂一些，因为我们需要处理类型擦除和智能指针。我一般用std::any来存储不同类型的实例。

#include <unordered_map>
#include <any>
#include <memory>
#include <typeindex>
#include <stdexcept>

class Registry {
public:
    template<typename T>
    void registerInstance(std::shared_ptr<T> instance) {
        auto key = std::type_index(typeid(T));
        instances[key] = instance;
    }
    
    template<typename T>
    std::shared_ptr<T> lookup() {
        auto key = std::type_index(typeid(T));
        auto it = instances.find(key);
        if (it == instances.end()) {
            throw std::runtime_error("No instance registered for type");
        }
        return std::any_cast<std::shared_ptr<T>>(it->second);
    }
    
private:
    std::unordered_map<std::type_index, std::any> instances;
};

这里用std::type_index作为键，避免了字符串比较的性能开销。嗯，C++的模板让类型安全在编译期就得到了保证。

查找机制的演进

注册表的查找机制其实经历了几个阶段：

阶段	查找方式	特点
第一阶段	字符串名称查找	简单但容易拼写错误，无类型安全
第二阶段	类型（Class）查找	类型安全，编译期检查
第三阶段	注解/配置驱动	声明式，自动注册

我个人更推荐第二阶段的方式。为什么？因为字符串查找太容易出错了。我记得有一次在项目中，一个同事把"UserService"写成了"UserServcie"，结果查了半天才找到bug。

从注册表到Spring BeanFactory

说到注册表模式，就不得不提Spring的BeanFactory。它本质上就是一个超级注册表，但做了很多增强：

• 依赖注入：自动解析Bean之间的依赖关系
• 生命周期管理：支持初始化、销毁回调
• 作用域管理：单例、原型、请求、会话等
• AOP集成：可以在注册时动态代理

Spring的BeanFactory接口定义如下：

public interface BeanFactory {
    Object getBean(String name) throws BeansException;
    <T> T getBean(Class<T> requiredType) throws BeansException;
    boolean containsBean(String name);
    boolean isSingleton(String name) throws NoSuchBeanDefinitionException;
    // ... 更多方法
}

你看，getBean方法其实就是注册表的lookup操作。但Spring在背后做了大量工作：解析XML配置、扫描注解、处理循环依赖、生成代理对象...

注册表模式的适用场景

不是所有地方都需要注册表。我总结了几条经验：

• 适合：插件系统、服务定位、框架内核、测试替身注入
• 不适合：简单对象创建、局部依赖、性能极端敏感的场景

为什么性能极端敏感的场景不适合？因为每次lookup都有Map查找的开销，虽然很小，但在高频调用下会累积。我曾经在一个实时交易系统中做过测试，每秒10万次lookup，Map查找占了总时间的3%。后来改成了直接引用，性能提升了2%。

SVG：注册表模式核心结构图

总结

注册表模式看似简单，但它是理解IoC容器、服务定位器、甚至微服务注册发现的基础。说白了，它解决的就是“对象怎么找到它需要的依赖”这个问题。

我在实际项目中，一般会这样选择：

• 小项目（< 10个服务）：直接用简单的注册表，甚至手动注入
• 中项目（10-50个服务）：用自己封装的注册表，加上注解扫描
• 大项目（> 50个服务）：直接上Spring，别自己造轮子

记住一点：注册表是工具，不是目的。过度使用会让代码变得隐晦，调试困难。我见过一个项目，所有对象都从注册表获取，结果代码里全是registry.lookup()，可读性极差。适度使用，才是正道。

---