sqlalchemy中的连接池是线程安全的吗？

文档称连接池也不是为多线程设计的：

至关重要的是，当使用连接池时，以及扩展时 使用通过 create_engine() 创建的引擎， 连接不会与分叉进程共享。 TCP 连接是 表示为文件描述符，通常跨进程工作 边界，这意味着这将导致对文件的并发访问 描述符代表两个或多个完全独立的Python 口译员指出。

据我了解，如果我创建连接池：

self.engine = create_engine('postgresql://{user}:{password}@{host}:{port}/{db}'.format(
    user=Configuration().get(section='repository', option='user'),
    password=Configuration().get(section='repository', option='password'),
    host=Configuration().get(section='repository', option='host'),
    port=Configuration().get(section='repository', option='port'),
    db=Configuration().get(section='repository', option='database')
), echo=False, pool_size=3)

self.session = sessionmaker(self.engine, expire_on_commit=False)

然后打电话self.session()在不同的线程中，我将有 3 个不同的连接，它们在 N 个不同的线程中使用。 这是否意味着只有 3 个并发线程会执行某些工作，而其他线程将等待一个或多个线程调用session.close()？或者有可能 >2 个线程同时使用同一个连接？

NullPool 是否更安全（因为每个新会话都是一个新连接）？

self.engine = create_engine('postgresql://{user}:{password}@{host}:{port}/{db}'.format(
            user=Configuration().get(section='repository', option='user'),
            password=Configuration().get(section='repository', option='password'),
            host=Configuration().get(section='repository', option='host'),
            port=Configuration().get(section='repository', option='port'),
            db=Configuration().get(section='repository', option='database')
        ), echo=False, poolclass=NullPool)

一般问题：在这种情况下使用相同的连接池是否可以：

engine = create_engine('connection_string', echo=False, pool_size=3)
Session = sessionmaker(engine)

def some_function():
    session = Session()
    ...

pool = Pool(processes=10)
pool.map(some_function)
pool.close()
pool.join()

总而言之，线程和进程之间似乎是混合的。该问题首先询问 SQLAlchemy 连接池是否是线程安全的，但以使用以下代码示例结束multiprocessing。对“一般问题”的简短回答是：不，如果使用分叉，则不应在进程边界上共享引擎及其关联的连接池。但也有例外。

池实现本身是线程安全的，并且通过代理Engine也是线程安全的，因为引擎除了保留对池的引用之外，不保留状态。另一方面，从池中签出的连接是not线程安全, and 两者都不是Session.

文档称连接池也不是为多线程设计的：

有一点误读，因为文档中的原始引用是关于共享连接池的process边界（如果使用分叉）。这可能会导致麻烦，因为在 SQLAlchemy 和 DB-API 层下面通常有一个 TCP/IP 套接字或文件句柄，而这些不应该同时操作。

在这种特殊情况下使用NullPool会是安全的，而其他的则不然，因为它根本不池化，因此连接不会在进程之间共享，除非有人不遗余力地这样做。

这是否意味着只有3个并发thread将执行一些工作，而其他工作将等待一个或多个线程调用session.close()?

假设一个QueuePool在使用中，设置的大小不是硬性限制，并且有一定的溢出空间。大小决定了池中持久保留的连接数。如果达到溢出限制，调用将等待timeout放弃并提出之前的几秒钟TimeoutError，如果没有可用的连接。

或者有可能 >2threads会同时使用同一个连接吗？

两个或更多threads将无法意外地从池中检出相同的连接，除了StaticPool，但可以在之后在线程之间显式共享它（不要）。

到底，“使用引擎和连接 - 基本用法”涵盖了问题的主要部分：

单个Engine代表进程管理许多单独的 DBAPI 连接，并且旨在以并发方式调用[强调]。

...

对于使用的多进程应用程序os.fork系统调用，或者例如Pythonmultiprocessing模块，通常需要一个单独的Engine用于每个子进程。这是因为Engine维护对连接池的引用，该连接池最终引用 DBAPI 连接 - 这些连接往往不可跨进程边界移植。一个Engine配置为不使用池化（这是通过使用NullPool）没有这个要求。