多线程的目的并不在于提供CPU的执行效率，而且在于多个事务的准并行处理。

准并行的涵义在于并不是同时的，单核的CPU一个时刻只能执行一条机器指令。

多线程是将CPU的PC指针运行分解为非常小的时间片，将这些时间片分配在不同的进程，不同的线程之间运行。

这样CPU就不至于长时间堵塞在某一些事务中，导致其它事务没有办法处理。

比如某个软件在进行大数据的收发或者运算时，需要刷新显示界面以及人机交互。

假设数据的收发或者运算需要数秒时间，如果用单线程，在做数据处理的几秒时间内，没办法显示人机交互，则用户在界面上做操作，程序就没有任何响应。

当活动线程数与CPU内核数相同时，速度最快。因为没有上下文切换开销，而且它可以满CPU运行。这是理想情况下的绝对峰值。

当然，在实际的程序中不可能如此理想。无论其他进程目前如何，如果程序中直接使用线程，较大的程序需要相当多的线程来处理不同的任务。

因此，在线程之上，我们将封装线程池，以控制线程数量，并减少线程创建和销毁的开销。业务逻辑只面向上层接口，如任务和队列。

即使使用在线进程池，仍然会出现问题。因为我们想要的是“活动”线程的数量与CPU内核的数量一致，也就是说，处于阻塞状态的线程不被计数，但线程阻塞在开发中是不可避免的。因此，一些人建议线程池中的最大线程数应该是CPU内核数的两倍左右。还有一些技术允许线程池在活动线程不足时自动扩展。

阻塞有两个主要来源：一个是由锁定引起的，另一个是由同步IO/网络请求引起的。请注意，后者在过去仍然很常见，但从当前的角度来看，我们应该优先考虑异步调用，而不是阻塞线程同步调用。异步方式在协作过程中是最好的，不应考虑回调。不建议使用同步呼叫。当同步接口在不必要的场合被广泛使用时，线程的数量必然会激增。

然后讨论锁的问题。在确保线程安全的情况下，它有时是一种技能测试，以尽量减少锁对性能的影响。但令人沮丧的是，当业务非常复杂时，很难不犯错误。据我所知，在国内一线移动应用中，线程安全问题导致的崩溃占总数的1/3以上。

是多线程编程的固有问题，基本上没有很好的方法。但我们可以跳出多线程编程的框架。2

考虑一个问题。线程安全的根本原因是什么？这是资源共享，更具体地说，是共享内存造成的问题。

并发编程一般有两种方式：一种是共享内存进行通信，即经典的多线程模型；总之，通过CSP模式发送消息的成本是不安全的。例如，通过CSP模式发送消息的成本是不安全的。当然，它可以从其他模型中消除，例如通过CSP发送消息。这取决于选择。

在过去两年中，后者得到了越来越广泛的应用，如go（非强制性但推荐），如fluent（强制性）。就这些。

一般说是"cpu核数X2"的线程数为最高效率的，但这是理想状态，仅指cpu的执行效率。实际的线程事务处理过程并不会始终流畅如一，往往会被存储访问、设备访问、通信速度等等因素制约着，所以，线程少了的话，系统整体执行效率肯定不高。并且，出于事务隔离、编程的简单化等考虑，也需要多开线程，绝不会是“cpu数x2”最佳。