在多线程项目开发时,最常用、最常遇到的问题是
1,线程、协程安全
2,线程、协程间的通信和控制
本文主要探讨不同开发语言go、java、python在进程、线程和协程上的设计和开发方式的异同。
进程
进程是操作系统进行资源分配的基本单位,每个进程都有自己的独立内存空间,不同的进程之间无法相互干扰。由于进程比较重,占据独立的内存,所以上下文进程间的切换开销(栈、寄存器、虚拟内存、文件句柄等)比较大,但相对比较稳定安全。
线程
线程又叫做轻量级进程,是进程的一个实体,是处理器任务调度和执行的基本单位位(能够申请到cpu资源执行相关任务)。它是比进程更小的能独立运行的基本单位。线程只拥有一点在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。
线程的执行需要申请对应的cpu资源,因此线程切换涉及CPU的资源切换(保存cpu上下文、触发软中断暂停当前线程、从就绪线程中选择一个执行),过程中会涉及用户态 -> 内核态(切换cpu)-> 用户态的切换,因此开销比较大。
协程
协程,又称微线程,是一种用户态的轻量级线程,协程的调度完全由用户控制(也就是在用户态执行)。协程拥有自己的寄存器上下文和栈。协程调度切换时,将寄存器上下文和栈保存到线程的堆区,在切回来的时候,恢复先前保存的寄存器上下文和栈,直接操作栈则基本没有内核切换的开销,可以不加锁的访问全局变量,所以上下文的切换非常快(协程切换,线程不变,因此不需要切换cpu,不进行内核态切换,成本较低)。
线程进程的区别:
协程与线程的区别:
进程占用内存
线程占用内存
协程占用内
内存占用: 进程 >> 线程 >> 协程
更低的内存占用代表着更低的资源切换成本和可以提供更高的并发。
进程切换,需要执行如下2个步骤
线程切换
协程切换
切换成本: 进程切换 > 线程切换 > 协程切换
线程、协程之间的通信主要用于2个目的
通常使用如下方法进行线程同步,可以根据实际情况调整
更多可以参考 python的多线程及线程间的通信方式
通常使用如下方法进行线程同步,可以根据实际情况调整
更多可以参考 Java线程间的通信
在go中,常用的是协程(goroutine)进行多并发,因此探讨的通信方式都是以协程(goroutine)进行讨论。
实现多个goroutine间的同步与通信大致有:
这3种方法具体实现可以参考文档 深入golang之—goroutine并发控制与通信
线程池的基类是 concurrent.futures 模块中的 Executor,Executor 提供了两个子类,即 ThreadPoolExecutor 和 ProcessPoolExecutor,其中 ThreadPoolExecutor 用于创建线程池,而 ProcessPoolExecutor 用于创建进程池。
由于全局GIL锁存在,python多线程本质上同一时间只能1个线程在执行,并不能高效的利用所有的CPU核心。
1, 如果使用多线程,线程的类型基本都是IO密集型,线程进入IO等到时会自动释放GIL索引,因此GIL锁的存在对于这种类型的计算性能影响不算大
2,如果使用多线程,线程的类型基本都是CPU密集型,只能等待解释器不间断运行了1000字节码(Py2)或运行15毫秒(Py3)后,该线程也会放弃GIL,切换到其他的线程执行。
使用线程池来执行线程任务的步骤如下:
def test(value1, value2=None):
print("%s threading is printed %s, %s"%(threading.current_thread().name, value1, value2))
time.sleep(2)
return 'finished'
def test_result(future):
print(future.result())
if __name__ == "__main__":
import numpy as np
from concurrent.futures import ThreadPoolExecutor
threadPool = ThreadPoolExecutor(max_workers=4, thread_name_prefix="test_")
for i in range(0,10):
future = threadPool.submit(test, i,i+1)
threadPool.shutdown(wait=True)
更多使用参考PYTHON线程池及其原理和使用(超级详细)
常用4中类型的线程池
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}
从构造方法可以看出,它创建了一个固定大小的线程池,每次提交一个任务就创建一个线程,直到线程达到线程池的最大值nThreads。线程池的大小一旦达到最大值后,再有新的任务提交时则放入无界阻塞队列中,等到有线程空闲时,再从队列中取出任务继续执行。
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());
}
从构造方法可以看出,它创建了一个可缓存的线程池。当有新的任务提交时,有空闲线程则直接处理任务,没有空闲线程则创建新的线程处理任务,队列中不储存任务。线程池不对线程池大小做限制,线程池大小完全依赖于操作系统(或者说JVM)能够创建的最大线程大小。如果线程空闲时间超过了60秒就会被回收。(使用方法不是非常推荐)
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>()));
}
从构造方法可以看出,它创建了一个单线程化的线程池,它只会用唯一的工作线程来执行任务,保证所有任务按照指定顺序执行。
public class OneMoreStudy {
public static void main(String[] args) {
final SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss");
ScheduledExecutorService scheduledThreadPool = Executors.newScheduledThreadPool(3);
System.out.println("提交时间: " + sdf.format(new Date()));
scheduledThreadPool.schedule(new Runnable() {
@Override
public void run() {
System.out.println("运行时间: " + sdf.format(new Date()));
}
}, 3, TimeUnit.SECONDS);
scheduledThreadPool.shutdown();
}
}
这个方法创建了一个固定大小的线程池,支持定时及周期性任务执行
根据使用习惯选择合适的方法类,更多可以参考Java中常用的四种线程池
go的基础方法类中没有实现线程池,需要自己实现,或者引入第三方库进行实现。
梳理常用的开发语言中,是有已经有了现成的线程池方法(类)提供使用,情况如下:
开发语言 | 是否支持线程池 | 备注 |
---|---|---|
python | 是 | |
java | 是 | |
go | 否 | 可以引用第三方的库或者自己实现 |
go的协程已经把单个协程的成本降低到足够低,还有必要设计线程池吗?该问题在Go Forum 中 skillian 做了解答。
我引用回复
Like lutzhorn said: Need? No.
But for some workloads in some projects, it might make sense to have a general worker pool implementation. The benefit is that the memory consumption can be limited by not allowing the number of goroutines to exceed whatever the pool allows, though I’m unsure of what order of magnitude of goroutines you need before that benefit is manifested.
Francesc Campoy created a fractal with 4 million goroutines (link 55) and it worked and scaled, but not perfectly. The issue wasn’t with the number of goroutines but that the runtime spent more time managing the goroutines than the goroutines actually worked. By giving the goroutines more work, (I think instead of each goroutine processing only one pixel, they processed the whole line?) the solution still scaled and ended up performing better.
翻译过来就是
1, 通常不需要
2, 除了特殊场景,特殊项目上,线程池是有意义的。这样做的好处是,可以通过不允许超过池允许的程序的数量来限制内存消耗,尽管我不确定在显示出这种好处之前需要多少量级的程序。