多线程Python素数计算脚本出现不一致错误，疑因未用time.sleep？

嘿，先直接给结论：你遇到的不一致错误几乎肯定不是因为没加time.sleep()，问题的核心大概率出在多线程对共享数据的非线程安全操作上。

从你贴的代码片段来看，你的线程类myThread会调用delete_non_primes函数——如果这个函数是在修改一个全局的素数标记集合（比如埃氏筛里的布尔数组），那多个线程同时读写这个共享资源时，就会触发竞态条件（Race Condition）：比如线程A刚把某个数标记为非素数，线程B同时也在操作同一个位置，直接把线程A的修改覆盖或者搞乱，最终导致每次运行的结果都不一致。

为啥time.sleep()背不了这个锅？ #

• time.sleep()只是让线程暂停一会儿，它最多能碰巧掩盖竞态问题（比如让线程执行顺序变得“看起来”有序），但根本解决不了线程安全的核心矛盾。就算你加了sleep，换个性能更高的机器或者并发量上来，错误还是会出现。
• 真正的问题是：多个线程在没有同步机制的情况下，直接操作同一块共享数据。

给你两个可行的解决方向： #

1. 加线程锁控制共享资源访问
   用threading.Lock()给共享数据的读写操作加锁，同一时间只允许一个线程修改数据。举个简单的例子：

   # 先定义一个全局锁
   prime_lock = threading.Lock()
   
   def delete_non_primes(counter):
       global prime_lock, prime_flags  # 假设prime_flags是共享的素数标记数组
       # 用with语句自动管理锁的获取和释放
       with prime_lock:
           # 把你的非素数标记/删除逻辑放在这里
           pass
   

2. 让线程处理独立区间，避免共享数据竞争
   把你要检查的数值范围分成几个独立的区间，每个线程负责筛选一个区间里的素数，最后把各个线程的结果汇总到一起。这种方式完全不需要锁，因为每个线程操作的是自己独有的数据，自然不会有冲突。

另外，你贴的代码有点不完整，如果delete_non_primes的逻辑不是操作共享数据，那可能需要你补充更多细节，但从常见的多线程素数筛选场景来看，线程安全问题是最可能的罪魁祸首。

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