0%

读《Java并发》— 并发简史

这一章主要讲述线程的发展历史,以及并发编程带来的优势和挑战。

1. 线程的发展

1946年第一台计算机诞生,一直到20世纪50年代中期,这时候的计算机没有操作系统的概念,采用手工操作的方式工作,每次只能有一个人使用计算机。此时的手工操作方式,用户独占全机,昂贵的计算机资源得不到充分利用。

后来,随着计算机的发展,出现了批处理系统、多道程序系统,它们都提升了计算机的资源利用率。1961年,分时系统(Time Sharing System)出现,此时的一台计算机可以供多个用户终端同时连接并使用,就好像自己在独占计算机一样。分时系统将CPU的运行时间分成很短的时间片,按时间片分配给不同的连接终端使用,这充分利用了计算机资源,看起来就好像多个用户在同时使用计算机一样。

再后来,通用操作系统出现(General Operating System),它隐藏了硬件调用接口,为应用程序员提供调用硬件资源的更好、更简单、更清晰的系统调用接口,程序员就可以直接面向操作系统来编写程序,而不用关注硬件。

计算机的发展 [1],都在试图解决三个问题:

  • 资源利用率:尽可能的利用昂贵的计算机资源,如CPU、内存,而不是使其大部分时间处于等待状态

  • 公平性:不同的用户对计算机都有同等使用权,而不是排队等待

  • 便利性:可以同时执行多个程序,每个程序执行一个任务并在必要时相互通信

这三个问题促使进程和线程的出现。计算机可以同时运行多个程序,每个程序一个进程;而同一个进程中同样存在多个线程(轻量级进程),它们共享进程范围内的资源,如内存句柄和文件句柄,每个线程都有自己的程序计数器、局部变量等,而且同一个进程的多个线程都可以被调度到CPU上运行。但是,线程之间存在着共享资源(进程的内存),如果没有协同机制,那么多个线程在同时处理共享内存时会存在安全问题,比如一个线程读某个变量而一个线程同时在写这个变量,如果没有线程同步机制,则该变量的值变得不可预测。

举个例子,假设进程为多条高速公路,它们之间彼此独立,而线程就好比高速公路的多个车道,它们共享这条高速路的资源,如指示牌、测速设备等,线程中执行的任务就是一辆小汽车,它们相安无事的飞驰在自己的车道上,一旦它们开始抢夺道路资源,不遵守交通规则,超速、违规变道,那么后果可想而知。

2. 多线程的优势

Java是门支持并发编程的语言,充分利用其提供的并发特性来编写高并发程序,是信息化时代发展所需。多线程程序的优势可以从几个方面来说明:

  • 多线程程序能够极大的发挥处理器的强大能力。现代的计算机,CPU核心越来越多、处理频率越来越快、制造工艺越来越精,计算机的价格也越来越亲民,个人普通电脑都普遍是四核心、八核心甚至配置更高。在单核心CPU中,可能多线程程序不但没能提升处理性能,反而由于线程上下文切换的开销导致程序性能降低;但是,在多核心时代,多线程能够发挥处理器的强大能力,每个核心都能同时处理一个任务而不会造成上下文切换,如果还停留在单线程程序,这无疑是极大的浪费计算机资源,如果有100个CPU,那么单线程程序会造成99%的CPU都处于空闲状态。

  • 建模更简单。首先要明确,编写多线程程序与单线程程序相比,肯定是复杂且容易出错的,那么为什么说建模更简单呢?这需要从管理线程中执行的任务角度去分析。在单线程中执行多个任务,与多个线程每个线程仅执行一个任务相比,哪个更容易管理呢?很明显是后者。虽然多线程中的任务彼此可能存在通信,但是从模型上看,一个线程只管理一个任务,职责更单一。

  • 异步事件简化处理。这一点可以理解为编程模型的简化。单线程和多线程程序,在IO模型的选择上存在很大的不同。单线程程序,要提高并发请求数,底层需要使用异步IO、非阻塞IO或者IO多路复用模型 [2],但他们都是由操作系统底层支持,编程难度大;而多线程程序,由于应用层面本身采用了多线程模型,底层的IO则可以选择同步IO(异步的事情多线程做了),这就降低了开发难度。比如单线程模型中,Nginx采用多进程单线程和IO多路复用模型的架构,具备极高的并发处理能力;Redis采用单线程和IO多路复用模型,同样具备很高的处理效率。

  • 响应更灵敏的用户界面。Java的GUI框架AWT和Swing采用事件分发线程来替代传统的主事件循环,并可将将耗时的处理任务放到单独的线程中异步执行,从而提高用户界面的响应速度。

3. 多线程的挑战

多线程是一把双刃剑,带来诸多优势时也让开发者面临更大的挑战。

1、开发难度问题

由于多线程程序运行的不确定性,给开发难度带来很大的挑战。相对于单线程程序,多线程编程更难以掌握,不仅需要充分理解编程语言级的多线程支持,还需要掌握操作系统层级的多线程模型。尽管如此,多线程程序仍然难以调试和跟踪,尤其是产生 "活跃性" 问题时往往无法重现。

2、安全性问题

什么是安全性?安全性指的是程序永远不会返回错误的结果。看下边的示例:

1
2
3
4
5
6
7
8
9
public class UnsafeSequence {
private int count;
public int increment() {
return count++;
}
public int getCount() {
return count;
}
}

多个线程调用 increment 方法,由于 count++ 包含了 读取、修改、写入三步内存操作,这三步不是一个原子操作,存在多个线程重复写同一值的情况,如下图示意:

1 1
Figure 1. 线程竞争导致错误的结果

由于线程在同时操作相同的count域,一个线程可能会覆盖另一个线程写入的值(线程竞争),最终count得到错误的值6,而不是预期的7.

线程安全本身是一个非常复杂的问题,由于线程之间存在资源共享,如果多个线程交替执行又没有有效的同步机制,执行结果将难以预料。尽管Java提供了足够的同步机制来保证线程安全性,但是这就要求开发者必须完全理解多线程程序的执行原理和Java的同步机制,这给程序开发带来很大的难度。

3、活跃性问题:

怎么理解活跃性?活跃性指的是如果线程存活则会保持运行,如果线程被销毁了当然就不活跃而是死亡了。说白了,如果线程还活着,那么它就能够 正确处理任务,即使它暂时被阻塞,但是如果后边它被唤醒后仍然能够继续运行。但是有时候,可能某些原因(比如程序bug),线程存活但是却始终得不到运行,或者运行着错误的任务,此时就产生了活跃性问题。最典型的活跃性问题就是 死锁,还包括 饥饿活锁

2.1 死锁

死锁指的是多个线程相互等待彼此而进入永久暂停状态。比如,线程 T1 持有锁 L1 去申请锁 L2,但是线程 T2 持有锁 L2 申请锁 L1,此时它们都在等待对象释放锁,从而进入永久阻塞状态。这就好比两个小朋友,他们各有一个玩具,但都不愿意分享给对方,却希望获得对方的玩具,最终互不相让,只能彼此干瞪眼了。

1 2
Figure 2. 死锁示意:小朋友争玩具,互不相让

死锁有一个著名的 哲学家就餐问题 (Dining philosophers problem),有兴趣的可以看这里

2.2 饥饿

饥饿(Starvation),指的是线程无法访问它需要的资源而不能继续运行。简单而言,饥饿是线程始终得不到运行时的状态,由于某些原因,线程始终得不到执行,所以产生饥饿现象。产生饥饿的原因很多,比如:

  1. 线程优先级设置不正确:CPU一直繁忙,但是线程被设置为低优先级,长时间得不到执行而变得"饥饿"

  2. 无限等待某一个资源:线程持有锁,内部由于某些原因造成了死循环,锁一直不能释放,那么其他需要逐个锁的线程就一直得不到执行而变得"饥饿"

2.3 活锁

活锁(Live Lock),指的是线程没有阻塞,仍然在运行,但是总在不断重复着某些错误的任务,也就是说,线程始终在做无用功。比如,程序编写了错误重试机制,而重试的次数被设置为无限次,一旦程序产生某些无法恢复的错误,那么线程就会一直重试着会出错的任务。

4、性能问题:

前边说了,多线程编程的目的是充分利用计算机资源、提高程序性能。但是,多线程同样存在性能问题,可能比单线程环境下性能还要低。你确定开100个线程就一定比1个线程快吗?答案是不确定。例如,多线程环境存在上下文切换(Context Switch)的开销,如果线程数量设置不当,不仅不能充分利用CPU资源,而且造成线程频繁地切换上下文,这需要保存和恢复线程当时的上下文信息,带来极大的性能开销;另一方面,线程之间必然存在数据共享,必须使用同步机制来串行化,此时会造成锁竞争,如果存在大量的锁竞争,势必会大大降低性能。

4. 掌握多线程

尽管多线程编程给我们带来了很大的挑战,但是其仍然是每个开发者都必须掌握的技术。信息时代高速发展的今天,计算机越来越普遍、性能越来越高,多线程技术是时代所需,而且线程无处不在。比如,在Java中,各类技术和框架都离不开多线程,从 JDBC 连接池分配和获取连接离不开线程,Servlet 每一个请求都开启一个线程来处理,Spring 中大量使用了线程池技术,RocketMQ 基于Java 多线程实现高并发等等。

过去,多线程编程是个 "高级话题",但是如今,多线程无处不在,每个开发者都必须掌握多线程编程,才能让我们成为信息时代的强者。

~赞赏是不耍流氓的鼓励😄~

欢迎关注我的其它发布渠道