为什么在r2d2连接池示例代码的循环中克隆Pool结构体？

先看一下你的代码示例：

fn main() { 
    let manager = r2d2_foodb::FooConnectionManager::new("localhost:1234"); 
    let pool = r2d2::Pool::builder() 
        .max_size(15) 
        .build(manager) 
        .unwrap(); 
    for _ in 0..20 { 
        let pool = pool.clone(); 
        thread::spawn(move || { 
            let conn = pool.get().unwrap(); 
        }) 
    } 
}

这个克隆操作主要有两个核心原因，都是围绕Rust的所有权规则和r2d2 Pool的设计来的：

1. 满足线程闭包的'static生命周期要求 #

thread::spawn创建的线程是脱离当前线程控制的，Rust要求传入的闭包必须是'static的——也就是说闭包捕获的变量不能有被外部代码提前销毁的风险。

如果我们不克隆pool，直接把原pool移动到闭包里，那么第一次循环迭代后，原pool的所有权就被转移到了第一个线程的闭包中，后续的循环迭代就没法再使用这个pool变量了（编译器会直接报错，因为变量已经被移走）。

而克隆后的pool实例，本质上是r2d2内部Arc<InnerPool>的一个新引用——Arc是原子引用计数的智能指针，只要有一个Arc实例存在，内部的连接池资源就不会被销毁。这样每个线程闭包拿到的克隆pool都是'static的（因为它的生命周期由引用计数管理，不受原变量的生命周期限制），完美符合thread::spawn的要求。

2. 克隆操作是轻量级的，没有性能负担 #

别担心克隆会带来额外开销！r2d2的Pool结构体本身就是围绕Arc设计的，调用clone()仅仅是增加了内部引用计数，完全不会复制整个连接池或者里面的数据库连接——这是一个非常廉价的操作，几乎可以忽略性能成本。

简单来说，克隆Pool就是给每个线程发了一个“连接池的访问凭证”，既遵守了Rust严格的所有权规则，又能让多个线程安全地共享同一个连接池资源。

内容的提问来源于stack exchange，提问作者Jonah Allerton