多线程并发查询Firestore时出现死锁问题

你的代码中，每个线程都重复创建Firestore客户端实例，这是触发稳定死锁的核心原因。Firestore的Python客户端设计为线程安全的单例对象，重复创建会引发底层gRPC连接池的锁竞争，最终导致死锁。当线程不同步时，连接池压力降低，锁竞争不足以触发死锁，因此问题不会显现。

修复方案 #

1. 复用全局Firestore客户端实例 #

将客户端初始化移到线程外部，全局复用同一个实例，避免重复创建带来的连接池竞争：

import threading
import firebase_admin
from firebase_admin import credentials, firestore

# 全局初始化Firebase应用与Firestore客户端，仅执行一次
__app = firebase_admin.initialize_app(credentials.ApplicationDefault())
db = firestore.client(__app)  # 全局复用该客户端实例

# Firestore查询函数
def query_firestore(docid):
    coll = db.collection("mycollection")
    try:
        print("About to query firestore")
        doc = coll.document(docid).get().to_dict()
        print(f"Document data: {doc}")
    except Exception as e:
        print(f"Error querying Firestore: {e}")

# 创建并启动多线程
def start_threads(n, docid):
    threads = []
    for _ in range(n):
        thread = threading.Thread(target=query_firestore, args=(docid,))
        threads.append(thread)
        thread.start()
    # 等待所有线程完成
    for thread in threads:
        thread.join()

if __name__ == "__main__":
    N = 5  # 线程数量
    docid = "1234"
    start_threads(N, docid)

2. 升级google-cloud-firestore版本 #

你测试的2.15.0和2.16.0版本确实存在多线程场景下的已知锁竞争问题，升级到>=2.17.0的稳定版本，官方已修复相关死锁bug。

3. 可选：调整gRPC线程策略 #

如果仍有问题，可以通过环境变量优化gRPC的线程行为：

export GRPC_POLL_STRATEGY=epoll1

核心原理说明 #

Firestore Python客户端内部维护了gRPC连接池，每个客户端实例会占用独立的连接资源。多线程下频繁创建/销毁客户端，会导致连接池的锁机制出现严重竞争，最终造成线程阻塞死锁。复用全局客户端实例可以避免这种资源竞争，同时符合官方推荐的最佳实践。

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