热加载的常见实现模式

说白了，热加载就一个核心诉求——不改代码、不重启进程，让参数生效。
但你想想看，不同的系统有不同的脾性，没有哪种模式能通吃所有场景。
我这些年踩过的坑告诉我：选择哪种模式，取决于你的系统对实时性、可靠性、资源消耗的容忍度。

我总结了四种最常见的实现模式。
它们各有千秋，也各有短板。嗯，咱们一个一个来看。

1. 轮询模式——最简单的保底方案

我遇到过很多人问我：“为什么轮询还能叫模式？不就是个死循环吗？”
嗯，这话对，也不全对。
轮询确实是最容易想到的方案。你开一个后台线程，每隔几秒读一次配置文件或远程配置中心，发现变了就加载新值。

我记得我刚入行那会儿，接手过一个老项目。就是用的轮询模式。
定时器设了30秒，每次全量加载一个 JSON 文件。
虽然粗暴，但胜在稳定。而且排查问题特别简单——大不了我就不等轮询了，手动触发一次 re-read 就行。

来个最简单的例子：

// ⚠️ 伪代码，重在演示轮询骨架
std::thread poll_thread([&]() {
    while (!stop_flag) {
        auto new_cfg = load_config_from_file("app.cfg");
        if (new_cfg != current_cfg) {
            apply_new_config(new_cfg);
            current_cfg = new_cfg;
        }
        std::this_thread::sleep_for(5s);
    }
});

这个代码，你看，核心就是三件事：读、比较、应用。
但有个细节容易踩坑——比较的逻辑。我见过有人用文件的修改时间来判定：

• 优点： 实现成本极低，几乎不会出 bug。不需要依赖任何特殊机制。
• 缺点： 有延迟；全量读取可能带来 IO 压力；如果配置源文件很大，每次解析开销不小。
• 适用场景： 非核心参数、边缘节点、测试环境、或对实时性不敏感的业务。

2. 信号驱动模式——中断式的高效方案

说白了，信号就是操作系统级别的“敲门声”。
你给进程注册一个信号处理函数，比如 SIGHUP。当你要更新配置时，就 kill -HUP <pid> 发一个信号过去。进程收到信号后，立刻重新加载配置。

我几年前做过一个网关服务，用的就是这个模式。
线上发版本时，运维同学只需要执行一条命令：

# 重载配置
kill -HUP $(cat /var/run/gateway.pid)

简单不？很酷也危险。
为什么说危险？因为信号处理函数里，你能做的事非常有限。
你可以设一个 flag，然后让主循环去检查。但千万别在信号处理里直接分配内存、锁资源、或者调用 printf——会出大问题。

volatile sig_atomic_t reload_flag = 0;

void signal_handler(int signo) {
    if (signo == SIGHUP) {
        reload_flag = 1;  // ✅ 只做这个
    }
}

// 主循环
while (running) {
    if (reload_flag) {
        reload_flag = 0;
        load_and_apply_config();  // 重载配置
    }
    // ... 处理正常业务
}

3. 代理/中间层模式——无侵入的优雅方案

这个模式，你想想看，最有意思。
你不需要改业务代码，不需要通知进程，甚至不需要重启。
只需要在逻辑中间加一层“代理”，每次拿参数的时候都通过它去访问配置。

我最早看到这种设计，是在一个自己写的配置管理库里。
它把配置对象包装成一个代理类。你平时调用的 config.get("timeout")，其实被代理拦截了。代理先去检查配置版本号有没有变，如果变了，就偷偷加载新配置，再返回新值给你。

什么感觉？就像中间商赚差价，但这个差价很有价值。

// 代理类的核心思想
class ConfigProxy {
public:
    int get_int(const string& key) {
        check_for_update();       // 检查是否需要重载
        return config_.get_int(key);
    }
private:
    void check_for_update() {
        if (version_file_has_changed()) {
            reload_config();      // 无感更新
        }
    }
    Config config_;
};

这样做的好处很明显：

• 业务代码完全无感知。它们只知道自己拿到的参数是最近的，根本不知道后台还在加载。
• 可以做到细粒度控制。比如某些 key 更新得快，某些 key 保持旧值。
• 回滚方便。如果新配置有问题，代理可以快速切换回旧版本。

4. 监听/回调模式——事件驱动的精准打击

这种模式，说白了就是“投喂制”。
你不需要自己去看文件有没有变，而是让配置中心或者文件系统在变化时主动通知你。
你注册一个回调函数，告诉系统“当这个参数变了，就调我”。

我遇到过很多人在用 etcd、Consul 或者 ZooKeeper 的时候，其实就是在用这种模式。
它们支持 watch 机制。客户端连上去，说“我要 watch /config/timeout 这个节点”。当有人修改了这个节点的值，服务端会主动 push 过来。

代码大概长这样：

// 假设有个配置中心客户端
config_center.watch("timeout", [](const std::string& new_value) {
    int new_timeout = std::stoi(new_value);
    g_timeout.store(new_timeout);       // 更新全局变量
    std::cout << "timeout 已更新为: " << new_timeout << "\n";
});

那么问题来了：回调里能做什么？能做的比信号处理多得多。
你可以解析数据、写日志、甚至触发其他更新。因为这是在正常的线程上下文里执行的。

但要注意：

• 回调不能阻塞。如果要做复杂操作，最好丢到一个队列里，由专门的线程处理。
• 小心重入。如果回调里又触发了另一个 watch 事件，可能会形成循环。
• 依赖基础设施。你需要部署配置中心，或者至少在文件系统上启用 inotify 之类的能力。