第一章: 走近Java
第二章: Java内存区域与内存溢出异常
第三章: Java垃圾收集器与内存分配策略
多任务处理是现代计算机几乎必备的功能,不仅是因为计算机的运算能力强大了,还有一个很重要的原因是计算机的运算速度与它的存储和通信子系统的速度差距太大,大量的时间花费在磁盘IO、网络通信或数据库访问上,为了不希望处理器在大部分时间里都处于等待其他资源的空闲状态,就必须使用一些手段压榨处理器的运算能力,否则会造成很大的性能浪费,而让计算机同时处理几项任务则是最容易想到的,也被证明是非常有效的压榨手段。
另外一种更具体的并发应用场景就是一个服务端同时对多个客户端提供服务。衡量一个服务性能的好坏,每秒事务处理数(TPS)是重要的指标之一,它代表着一秒内服务端平均能响应的请求总数,而TPS与程序的并发能力有非常密切的关系。对于计算量相同的任务,线程并发协调越有条不紊,效率越高;线程间竞争频繁,互相阻塞甚至死锁,将会大大降低程序并发能力。
服务端应用是Java语言擅长的领域之一。而Java语言和虚拟机提供了许多工具,将并发编程的门槛降低了不少,且各种中间件、各类框架等也可能隐藏线程并发细节,使得程序员在编码时更关注业务逻辑。
但是无论语言、中间件和框架再如何先进,开发人员都不应期望它们能独立完成所有并发处理的事情,了解并发的内幕仍然是成为一个高级程序员不可缺少的课程。
什么是高速缓存?为什么需要高速缓存
物理机绝大多数的计算任务都不可能只靠处理器计算完成,处理器至少要与内存交互,如读取运算数据、存储运算结果等,无法仅仅依靠寄存器完成所运算任务。由于计算机的存储设备与处理器的运算速度有几个数量级的差距,所以现代计算机不得不加入一层或多层读写速度尽可能接近处理器运算速度的高速缓存来作为内存与处理器之间的缓冲:将运算需要使用的数据复制到缓存中,让运算能快速进行,当运算结束后再从缓存同步回内存中,这样处理器就无须等待缓慢的内存读写了。
什么是缓存一致性问题?如何解决?
在多路处理器系统中,每个处理器都有自己的高速缓存,而它们又共享同一主内存,这种系统成为共享多核系统,当多个处理器的运算任务都涉及同一块主内存区域时,将可能导致各自的缓存数据不一致,如果发生这种情况,那同步回到主内存时该以谁的缓存数据为准呢?为了解决一致性问题,需要各个处理器访问缓存时遵循一些协议,在读写时要根据协议来进行操作,这类协议有MSI、MESI等。
内存模型可以理解为在特定的操作协议下,对特定的内存或高速缓存进行读写访问的过程抽象。不同架构的物理机器可以拥有不一样的内存模型。
除了增加高速缓存之外,为了使处理器内部的运算单元能尽量被充分使用,处理器可能会对输入代码进行乱序执行优化,处理器会在计算之后将乱序执行的结果重组,保证该结果与顺序执行的结果是一致的,但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致,因此如果存在一个计算任务依赖另外一个计算任务的中间结果,那么其顺序性并不能靠代码的先后顺序来保证。与处理器的乱序执行优化类似,Java虚拟机的即时编译器也有指令重排序优化。
Java内存模型屏蔽各种硬件和操作系统的内存访问差异,以实现让Java程序在各种平台下都能达到一致的内存访问效果。
Java内存模型的主要目的是定义了程序中各种变量的访问规则,即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层操作细节。这里的变量包括了实例字段、静态字段和构成数组对象的元素,但是不包括局部变量与方法参数,因为后者是线程私有的,不会被共享,自然就不存在竞争问题,且为了获得更好的执行效能,Java内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互,也没有限制即时编译器是否需要进行调整代码执行顺序这类优化措施。
Java内存模型规定了所有的变量都存储在主内存中,每个线程还有自己的工作内存(类比高速缓存),线程的工作内存中保存了该线程使用的变量的主内存副本,线程对变量的所有读写操作都必须在工作内存中进行,而不能直接读写主内存中的数据,不同线程之间也无法直接访问对方工作内存中的变量,线程间变量值的传递都需要通过主内存来完成。如图:
关于主内存与工作内存之间具体的交互协议,即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存这一类的实现细节。Java内存模型定义了以下8种操作来完成,Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的:
如果将一个变量从主内存拷贝到工作内存中,就要按顺序执行read和load操作,如果把变量从工作内存同步回主内存,就要按顺序执行store和write操作。Java内存模型只要求上述两个操作必须顺序执行,但不要求是连续执行,即可能:read:a read:b load:b load:a。除此之外,Java内存模型还规定了在执行上述8种基本操作时必须满足如下规则:
关键字volatile是虚拟机提供的最轻量级的同步机制。
变量修饰为volatile有什么用?
1、保证此变量对所有线程的可见性,即当一条线程修改了这个变量的值,新值对于其他线程来说是可以立即得知的,而普通变量的值在线程间传递时均需要通过主内存来完成,例线程A修改一个普通变量的值后,然后向主内存进行回写,另外一条线程B在线程A回写完成后再对主内存进行读取操作,新变量值才对线程B可见。
volatile变量在各个线程的工作内存中是不存在一致性问题的(物理存储角度看,各个线程的工作内存中volatile变量也可以存在不一致的情况,但由于每次使用之前都要先刷新,执行引擎看不到不一致的情况,因此可以认为不存在一致性问题,但是Java里运算操作符并非原子操作(自增++、自减–等),这导致volatile变量的运算在并发下一样是不安全的)
由于volatile变量只能保证可见性,在不符合以下两条规则的运算场景下,仍然要通过加锁(synchronized、current并发包中的锁或原子类)来保证原子性:
-运算结果不依赖变量的当前值,或者确保只有单一的线程修改变量值
-变量不需要与其他的状态变量共同参与不变约束
2、禁止指令重排序优化,普通的变量仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果,而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致
什么是long和double的非原子性协定?
Java内存模型要求lock、unlock、read、load、assign、use、store、write这8种操作都具有原子性,但是对于64位的数据类型,在模型中定义了一条宽松的规定:允许虚拟机将没有被volatile修饰的64位数据类型的读写操作划分为两次32位的操作来进行,即允许虚拟机实现自行选择是否要保证64位数据类型的load、store、read、write这4个操作的原子性。
由Java内存模型直接保证的原子性变量操作包括read、load、assign、use、store和write这6个,大致可以认为,基本数据类型的访问、读写都是原子性的,此外更大范围的原子性保证,Java内存模型还提供了lock和unlock操作来满足需求,如更高层次的字节码指令monitorenter和monitorexit来隐式地使用,这两个字节码指令反映到Java代码中就是同步块-synchronized关键字
指当一个线程修改了变量值后,其他线程能够立即得知这个修改。volatile变量的特殊规则保证了新值能立即同步到主内存中,以及每次使用前立即从主内存刷新。
在本线程内观察,所有的操作都是有序的(线程内似表现为串行的语义);如果在一个线程中观察另一个线程,所有的操作都是无序的(指令重排序现象和工作内存与主内存同步延迟现象)。
为什么有这个规则?
如果Java内存模型中所有的有序性都依靠volatile和synchronized来完成,那么将会有很多操作变得非常啰嗦,但是我们在编写Java程序时并没有察觉到这一点,就是因为Java语言中有一个先行发生原则
什么是先行发生?
先行发生是Java内存模型中定义的两项操作之间的偏序关系。例如操作A先行发生于操作B,其实就是说在发生操作B之前,操作A产生的影响能够被操作B观察到,"影响"包括了修改内存中共享变量的值、发送消息、调用了方法等。
什么是Java内存模型的先行发生规则?
Java内存模型的先行发生规则有什么用?
满足上述先行发生规则的场景无需使用任何同步手段保障。
线程是比进程更轻量级的调度执行单元,线程的引入可以把一个进程的资源分配和执行调度分开,各个线程既可以共享进程资源(内存地址、文件IO等),又可以独立调度。
实现线程主要有三种方式:
内核线程指直接由操作系统内核支持的线程,由内核来完成线程切换,内核通过操纵调度器对线程进行调度,并负责将线程的任务映射到各个处理器上。
轻量级进程是内核线程的一种高级接口,也是我们通常意义讲的线程,每一个轻量级进程都由一个内核线程支持。
优劣:
每个轻量级进程都成为一个独立的调度单元,即使其中一个轻量级进程阻塞了,也不会影响整个进程继续工作。但由于是基于内核线程实现的,各种线程操作需要进行系统调用,代价相对较高,需要在用户态和内核态来回切换,且一个轻量级进程对应一个内核线程,轻量级进程要消耗一定的内核资源(内核线程的栈空间),因此一个系统支持轻量级进程的数据是有限的
用户线程指完全建立在用户空间的线程库上,系统内核不能感知到用户线程的存在及如何实现的。用户线程的创建、同步、销毁、调度完全在用户态中完成,不需要内核的帮助。如果程序实现得当,这种线程不需要切换到内核态,因此操作可以是非常快速且低消耗的,也能够支持更大的线程数量。
优劣:
用户线程的优势在于不需要系统内核支援,劣势也在于没有系统内核支援,所有的线程操作都需要用户程序自己去处理,因此用户线程实现的程序通常都比较复杂。
混合实现下,既存在用户线程,也存在轻量级进程。用户线程还是完全建立在用户空间中,因此用户线程的各种操作依然廉价,且可以支持大规模的用户并发。而操作系统支持的轻量级进程则作为用户线程和内核线程之间的桥梁,这样做可以使用内核提供的线程调度功能及处理器映射,并且用户线程的系统调用要通过轻量级进程来完成,大大降低了整个进程被完全阻塞的风险。
Java线程的实现并不受Java虚拟机规范的约束,这是一个与具体虚拟机相关的话题。
目前主流平台上的主流商用虚拟机的线程模型普遍使用基于操作系统原生线程模型实现,即1:1实现模型
Hotspot虚拟机中,它的每一个Java线程都是直接映射到一个操作系统原生线程来实现的,而且中间没有额外的间接结构,所以Hotspot是不会干涉线程调度的,全权交给底层的操作系统去处理。
线程调度指系统为线程分配处理器使用权的过程,调度主要方式有两种:协同式线程调度和抢占式线程调度。
协同式线程调度:
指线程的执行时间由线程本身控制,线程把自己的工作执行完后,要主动通知系统切换到另外一个线程上去。协同式调度的好处是实现简单且切换动作对自己本身是可知的,一般没有什么线程同步的问题;坏处是线程执行时间不可控,可能会一个线程阻塞影响整个进程或系统
抢占式线程调度:
指每个线程的执行时间由系统来分配,线程的切换不由线程本身决定。在这种实现线程调度方式下,线程的执行时间是系统可控的,也不会因为一个线程导致整个进程或系统阻塞
Java使用的线程调度方式是抢占式线程调度。Java语言一共设置了10个级别的线程优先级。当两个线程同时处于Ready状态时,优先级越高的线程越容易被系统选择执行(线程优先级并不是一项稳定的调节手段)。
Java语言定义了6种线程状态,在任意一个时间点中,一个线程只能有且只有其中的一个状态,并且可以通过特定的方法在不同状态之间转换:
目前Java线程面临的困境:对Web应用的服务要求,不论是在请求数量上还是在复杂度上,与十多年前相比已不可同日而语,这一方面是源于业务量的增长,另一方面来自于为了应对业务复杂化而不断进行的服务细分。现代B/S系统中一次对外部业务请求的响 应,往往需要分布在不同机器上的大量服务共同协作来实现,这种服务细分的架构在减少单个服务复杂度、增加复用性的同时,也不可避免地增加了服务的数量,缩短了留给每个服务的响应时间。这要求每一个服务都必须在极短的时间内完成计算,这样组合多个服务的总耗时才不会太长;也要求每一个服务提供者都要能同时处理数量更庞大的请求,这样才不会出现请求由于某个服务被阻塞而出现等待。
Java目前的并发编程机制就与上述架构趋势产生了一些矛盾,1:1的内核线程模型是如今Java虚拟机线程实现的主流选择,但是这种映射到操作系统上的线程天然的缺陷是切换、调度成本高昂,系统能容纳的线程数量也很有限。以前处理一个请求可以允许花费很长时间在单体应用中,具有这种线程切换的成本也是无伤大雅的,但现在在每个请求本身的执行时间变得很短、数量变得很多的前提下, 用户线程切换的开销甚至可能会接近用于计算本身的开销,这就会造成严重的浪费
为什么内核线程调度切换成本高?
内核线程的调度成本主要来自于用户态与内核态之间的状态转换,而这两种状态转换的开销主要来自于响应中断、保护和恢复执行现场的成本
协程的主要优势是轻量。在64位Linux上HotSpot的线程栈容量默认是1MB,此外内核数据结构还会额外消耗16KB内存。与之相对的,一个协程的栈通常在几百个字节到几KB之间,所以Java虚拟机里线程池容量达到两百就已经不算小了,而很多支持协程的应用中,同时并存的协程数量可数以十万计
协程的局限是需要在应用层面实现的内容特定多