2025-03-26 ·
日常编程 ·
275273
Python单例模式的多线程与多进程行为分析
单例模式旨在确保一个类只有一个实例,并提供全局访问点。但在Python的多线程和多进程环境中,其表现有所不同。本文将深入探讨这种差异,并通过代码示例进行说明。
首先,我们来看一个简单的单例模式实现:
import multiprocessing
import threading
import time
def singleton(cls):
_instance = {}
def inner():
if cls not in _instance:
_instance[cls] = cls()
return _instance[cls]
return inner
@singleton
class SingletonClass:
count = 0
def __init__(self):
SingletonClass.count += 1
def worker(name):
for _ in range(10):
instance = SingletonClass()
instance.count += 1
time.sleep(0.1)
print(f"{name}: count = {SingletonClass.count}, id = {id(instance)}")
if __name__ == '__main__':
# 多线程测试
threads = [threading.Thread(target=worker, args=(f"Thread-{i}",)) for i in range(2)]
for thread in threads:
thread.start()
for thread in threads:
thread.join()
# 多进程测试 (注释掉多线程部分后运行)
# processes = [multiprocessing.Process(target=worker, args=(f"Process-{i}",)) for i in range(2)]
# for process in processes:
# process.start()
# for process in processes:
# process.join()
在这个例子中,singleton 装饰器确保了 SingletonClass 的单例特性。worker 函数模拟了多个线程或进程对单例对象的访问。
运行多线程部分,你会发现所有线程共享同一个 SingletonClass 实例,id(instance) 的值始终相同,count 变量也正确地递增。
然而,如果取消多线程部分的注释,并运行多进程部分,你会观察到每个进程都创建了自己的 SingletonClass 实例,id(instance) 的值在不同进程中不同,count 变量在每个进程中独立递增。
这是因为:
多线程: 所有线程共享同一个进程的内存空间,因此单例模式的全局变量 _instance 对所有线程可见,从而保证了单例的唯一性。
多进程: 每个进程拥有独立的内存空间,因此每个进程都拥有自己独立的 _instance 变量副本,导致每个进程都创建了 SingletonClass 的一个新实例。
因此,在多进程环境下,上述简单的单例模式实现并不能保证单例的唯一性。如果需要在多进程环境下实现真正的单例模式,需要采用更高级的技术,例如使用 multiprocessing.Manager 创建共享内存或使用进程间通信机制。
这个修改后的例子更清晰地展现了单例模式在多线程和多进程环境下的行为差异,并解释了其根本原因。 它避免了原例子的冗余代码,并更简洁地说明了关键概念。
以上就是单例模式在多线程和多进程环境下如何表现?的详细内容,更多请关注骃骐网【www.myinqi.com】。
单纯用zipfile.ZipFile.extractall()解大型ZIP文件速度慢,因其本质是单线程顺序处理,不支持并发;有效提速方式是用ThreadPoolExecutor并发调用extract(),每个线程独立打开ZIP文件处理单个条目,并注意编码兼容、内存控制与线程安全。 单纯用 zipfile.ZipFile.extractall() 解大型 ZIP 文件,基本就是单核硬扛,速度瓶颈明显...
2026-05-29 · 日常编程 · 161326
RabbitMQ本身保证单条消息只投递一次给一个消费者,数据一致性问题源于业务逻辑并发执行导致的竞态,而非消息重复投递;basic_ack仅确认消息接收,不保障业务执行唯一性,故无法解决数据一致性问题。 多进程消费同一个RabbitMQ队列时,数据一致性问题不来自RabbitMQ本身(它天然保证单条消息只投递一次给一个消费者),而来自业务逻辑并发执行导致的竞态——比如多个进程同时读写同一张数据库表...
2026-05-29 · 日常编程 · 36571
ProcessPoolExecutor比手写Process更稳,因其内置进程复用、超时控制、异常透传;避免AttributeError需将函数置于模块顶层且非lambda/嵌套;max_workers应据内存与任务粒度调优,而非盲目设为cpu_count()。 训练模型时 CPU 占用率“过高”不是 bug,而是 multiprocessing 正常工作的表现——它真正在压满多核,而不是像 thr...
2026-05-29 · 日常编程 · 299423
pytest测多线程安全会“测不准”是因为其单线程执行机制导致测试函数返回即判定完成,后台线程可能未结束;必须用join显式同步、Event/Lock制造竞态、捕获线程异常并共享被测对象。 为什么直接用 pytest 测多线程安全会“测不准” 因为 pytest 默认是单线程执行测试函数,即使你在测试里手动启动多个 threading.Thread,它也不会自动等待所有线程结束就判定测试通过——t...
2026-05-29 · 日常编程 · 69540
subprocess.check_output 默认吞掉 stderr 且不暴露,仅当退出码非零才抛异常;需改用 subprocess.run(..., capture_output=True, check=True) 分别获取 stdout 和 stderr。 subprocess.check_output 会吞掉 stderr 吗 会,而且默认情况下完全不暴露 stderr。调用 subpro...
2026-05-29 · 日常编程 · 107831
Django 的 send_mail 是同步阻塞调用,会导致视图卡住、HTTP 超时、worker 占满等问题;应改用 threading(轻量)或 Celery+Redis(生产),并优先使用 EmailMessage 支持 HTML、附件等功能。 同步 send_mail 会卡住视图,别直接用 Django 的 send_mail 是纯同步阻塞调用,SMTP 连接、TLS 协商、认证、发信全程...
2026-05-26 · 日常编程 · 125413
不能直接在async函数里用openpyxl或pandas.to_excel,因为二者均为同步阻塞调用,会卡住event loop;即便用await asyncio.to_thread()包装,Excel写入本质是CPU密集型操作,受GIL限制,线程无法真正并行,反而降低性能;必须改用multiprocessing+asyncio.run_in_executor组合,将Excel构建移至独立子进程...
2026-05-25 · 日常编程 · 163830
准确判断DDP中rank 0主进程需先检查torch.distributed.is_initialized()为True,再调用torch.distributed.get_rank()==0;单卡调试时可默认rank 0,但生产环境必须显式初始化且在模型封装前完成。 如何准确判断 DDP 中的 rank 0 主进程 DDP(DistributedDataParallel)下,torch.distr...
2026-05-24 · 日常编程 · 163391
pyodbc 支持多进程和多线程并行数据库操作,但连接必须在各进程/线程内独立创建;直接复用连接会导致错误。实际性能瓶颈常在 i/o 而非 cpu,因此线程池通常比进程池更高效、资源更轻量。 pyodbc 支持多进程和多线程并行数据库操作,但连接必须在各进程/线程内独立创建;直接复用连接会导致错误。实际性能瓶颈常在 i/o 而非 cpu,因此线程池通常比进程池更高效、资源更轻量。 在 Python...
2026-05-24 · 日常编程 · 14982
本文探讨在 Laravel 5.8 环境下,如何通过重启队列工作进程来管理长时间运行或异常的队列任务,特别是当面临难以直接删除的超长延迟任务时。核心策略是利用 php artisan queue:work --stop-when-empty 命令实现工作进程的优雅关闭和重启,确保队列系统健康运行。理解 Laravel 队列中的任务管理挑战 在 Laravel 队列系统中,特别是当任务被配置了极长的...
2025-08-28 · 日常编程 · 225289