python多线程假的
Ⅰ python的多线程是真的多线程吗
简单地说就是作为可能是仅有的支持多线程的解释型语言（perl的多线程是残疾，PHP没有多线程），Python的多线程是有compromise的，在任意时间只有一个Python解释器在解释Python bytecode。
UPDATE：如评论指出，Ruby也是有thread支持的，而且至少Ruby MRI是有GIL的。
如果你的代码是CPU密集型，多个线程的代码很有可能是线性执行的。所以这种情况下多线程是鸡肋，效率可能还不如单线程因为有context switch
但是：如果你的代码是IO密集型，多线程可以明显提高效率。例如制作爬虫（我就不明白为什么Python总和爬虫联系在一起…不过也只想起来这个例子…），绝大多数时间爬虫是在等待socket返回数据。这个时候C代码里是有release GIL的，最终结果是某个线程等待IO的时候其他线程可以继续执行。
反过来讲：你就不应该用Python写CPU密集型的代码…效率摆在那里…
如果确实需要在CPU密集型的代码里用concurrent，就去用multiprocessing库。这个库是基于multi process实现了类multi thread的API接口，并且用pickle部分地实现了变量共享。
再加一条，如果你不知道你的代码到底算CPU密集型还是IO密集型，教你个方法：
multiprocessing这个mole有一个mmy的sub mole，它是基于multithread实现了multiprocessing的API。
假设你使用的是multiprocessing的Pool，是使用多进程实现了concurrency
from multiprocessing import Pool
如果把这个代码改成下面这样，就变成多线程实现concurrency
from multiprocessing.mmy import Pool
两种方式都跑一下，哪个速度快用哪个就行了。
UPDATE:
刚刚才发现concurrent.futures这个东西，包含ThreadPoolExecutor和ProcessPoolExecutor，可能比multiprocessing更简单
Ⅱ python多进程和多线程的区别
进程是程序（软件，应用）的一个执行实例，每个运行中的程序，可以同时创建多个进程，但至少要有一个。每个进程都提供执行程序所需的所有资源，都有一个虚拟的地址空间、可执行的代码、操作系统的接口、安全的上下文（记录启动该进程的用户和权限等等）、唯一的进程ID、环境变量、优先级类、最小和最大的工作空间（内存空间）。进程可以包含线程，并且每个进程必须有至少一个线程。每个进程启动时都会最先产生一个线程，即主线程，然后主线程会再创建其他的子线程。
线程，有时被称为轻量级进程(Lightweight Process，LWP），是程序执行流的最小单元。一个标准的线程由线程ID，当前指令指针(PC），寄存器集合和堆栈组成。另外，线程是进程中的一个实体，是被系统独立调度和分派的基本单位，线程自己不独立拥有系统资源，但它可与同属一个进程的其它线程共享该进程所拥有的全部资源。每一个应用程序都至少有一个进程和一个线程。在单个程序中同时运行多个线程完成不同的被划分成一块一块的工作，称为多线程。
举个例子，某公司要生产一种产品，于是在生产基地建设了很多厂房，每个厂房内又有多条流水生产线。所有厂房配合将整个产品生产出来，单个厂房内的流水线负责生产所属厂房的产品部件，每个厂房都拥有自己的材料库，厂房内的生产线共享这些材料。公司要实现生产必须拥有至少一个厂房一条生产线。换成计算机的概念，那么这家公司就是应用程序，厂房就是应用程序的进程，生产线就是某个进程的一个线程。
线程的特点：
线程是一个execution context（执行上下文），即一个cpu执行时所需要的一串指令。假设你正在读一本书，没有读完，你想休息一下，但是你想在回来时继续先前的进度。有一个方法就是记下页数、行数与字数这三个数值，这些数值就是execution context。如果你的室友在你休息的时候，使用相同的方法读这本书。你和她只需要这三个数字记下来就可以在交替的时间共同阅读这本书了。
线程的工作方式与此类似。CPU会给你一个在同一时间能够做多个运算的幻觉，实际上它在每个运算上只花了极少的时间，本质上CPU同一时刻只能干一件事，所谓的多线程和并发处理只是假象。CPU能这样做是因为它有每个任务的execution context，就像你能够和你朋友共享同一本书一样。
进程与线程区别：
同一个进程中的线程共享同一内存空间，但进程之间的内存空间是独立的。
同一个进程中的所有线程的数据是共享的，但进程之间的数据是独立的。
对主线程的修改可能会影响其他线程的行为，但是父进程的修改（除了删除以外）不会影响其他子进程。
线程是一个上下文的执行指令，而进程则是与运算相关的一簇资源。
同一个进程的线程之间可以直接通信，但是进程之间的交流需要借助中间代理来实现。
创建新的线程很容易，但是创建新的进程需要对父进程做一次复制。
一个线程可以操作同一进程的其他线程，但是进程只能操作其子进程。
线程启动速度快，进程启动速度慢（但是两者运行速度没有可比性）。
由于现代cpu已经进入多核时代，并且主频也相对以往大幅提升，多线程和多进程编程已经成为主流。Python全面支持多线程和多进程编程，同时还支持协程。
Ⅲ 关于python多线程的一些问题。
创建的子线程默认是非守护的。
非守护：当主线程结束时，子线程继续运行，二者互不影响。
子线程是守护线程：当主线程结束时，子线程也结束（不管子线程工作有没有完成）。
join作用是线程同步，是让主线程等待子线程结束才结束（主线程完成工作了也不结束，阻塞等待，等子线程完成其工作才一起结束）。
相信此时你已经懂你的两个问题了。
没加join的时候主线程结束了，所以命令提示符>>>就出来了，可是子线程还没结束，过了3/5秒后打印了字符串。加了join后主线程等两个子线程都结束才一起结束，所以最后才出来>>>。
理解确实有点偏差。守护是指子线程守护着主线程，你死我也死，谓之守护。
Ⅳ Python实现简单多线程任务队列
Python实现简单多线程任务队列
最近我在用梯度下降算法绘制神经网络的数据时，遇到了一些算法性能的问题。梯度下降算法的代码如下（伪代码）：
defgradient_descent(): # the gradient descent code plotly.write(X, Y)
一般来说，当网络请求 plot.ly 绘图时会阻塞等待返回，于是也会影响到其他的梯度下降函数的执行速度。
一种解决办法是每调用一次 plotly.write 函数就开启一个新的线程，但是这种方法感觉不是很好。 我不想用一个像 cerely（一种分布式任务队列）一样大而全的任务队列框架，因为框架对于我的这点需求来说太重了，并且我的绘图也并不需要 redis 来持久化数据。
那用什么办法解决呢？我在 python 中写了一个很小的任务队列，它可以在一个单独的线程中调用 plotly.write函数。下面是程序代码。
classTaskQueue(Queue.Queue):
首先我们继承 Queue.Queue 类。从 Queue.Queue 类可以继承 get 和 put 方法，以及队列的行为。
def__init__(self, num_workers=1): Queue.Queue.__init__(self) self.num_workers=num_workers self.start_workers()
初始化的时候，我们可以不用考虑工作线程的数量。
defadd_task(self, task,*args,**kwargs): args=argsor() kwargs=kwargsor{} self.put((task, args, kwargs))
我们把 task, args, kwargs 以元组的形式存储在队列中。*args 可以传递数量不等的参数，**kwargs 可以传递命名参数。
defstart_workers(self): foriinrange(self.num_workers): t=Thread(target=self.worker) t.daemon=True t.start()
我们为每个 worker 创建一个线程，然后在后台删除。
下面是 worker 函数的代码：
defworker(self): whileTrue: tupl=self.get() item, args, kwargs=self.get() item(*args,**kwargs) self.task_done()
worker 函数获取队列顶端的任务，并根据输入参数运行，除此之外，没有其他的功能。下面是队列的代码：
我们可以通过下面的代码测试：
defblokkah(*args,**kwargs): time.sleep(5) print“Blokkah mofo!” q=TaskQueue(num_workers=5) foriteminrange(1): q.add_task(blokkah) q.join()# wait for all the tasks to finish. print“Alldone!”
Blokkah 是我们要做的任务名称。队列已经缓存在内存中，并且没有执行很多任务。下面的步骤是把主队列当做单独的进程来运行，这样主程序退出以及执行数据库持久化时，队列任务不会停止运行。但是这个例子很好地展示了如何从一个很简单的小任务写成像工作队列这样复杂的程序。
defgradient_descent(): # the gradient descent code queue.add_task(plotly.write, x=X, y=Y)
修改之后，我的梯度下降算法工作效率似乎更高了。如果你很感兴趣的话，可以参考下面的代码。 classTaskQueue(Queue.Queue): def__init__(self, num_workers=1):Queue.Queue.__init__(self)self.num_workers=num_workersself.start_workers() defadd_task(self, task,*args,**kwargs):args=argsor()kwargs=kwargsor{}self.put((task, args, kwargs)) defstart_workers(self):foriinrange(self.num_workers):t=Thread(target=self.worker)t.daemon=Truet.start() defworker(self):whileTrue:tupl=self.get()item, args, kwargs=self.get()item(*args,**kwargs)self.task_done() deftests():defblokkah(*args,**kwargs):time.sleep(5)print"Blokkah mofo!" q=TaskQueue(num_workers=5) foriteminrange(10):q.add_task(blokkah) q.join()# block until all tasks are doneprint"All done!" if__name__=="__main__":tests()