Java与线程

线程的实现

使用内核线程实现

内核线程(Kernel-Level Thread, KLT) 就是直接由 操作系统内核(Kernel) 支持的线程,这种线程由内核来完成线程切换,内核通过操纵调度器(Scheduler)对线程进行调度,并负责将线程的任务映射到各个处理器上.
每个内核可以视为内核的一个分身,这样操作系统就有能力同时处理多件事情,支持多线程的内核就叫做多线程内核(Multi-Threads Kernel).

程序一般不会直接去使用内核线程,而是去使用内核线程的一种高级接口, 轻量级进程(Light Weight Process, LWP)
轻量级进程就是我们通常意义上所讲的线程.
由于每个轻量级进程都由一个内核线程支持,因此只有先支持内核线程,才能有轻量级进程.
这种轻量级线程与内核线程之间1:1的关系被称为一对一的线程模型.

由于内核线程的支持,每个轻量级进程都成为一个独立的调度单元,即使有一个轻量级进程在系统调用中阻塞了,也不会影响到整个进程的工作.
由于基于内核线程实现,所以各种线程操作,如创建,析构以及同步,都需要进行系统调用,而系统调用的代价是相对较高的,需要在 用户态(User Mode) 和 内核态(Kernel Mode) 中来回切换.
其次,每个轻量级进程都需要有一个内核线程的支持,因此轻量级进程要消耗一定的内核资源,因此一个系统支持轻量级进程的数量是有限的.

使用用户线程

从广义上讲,一个线程只要不是内核线程,就可以认为是 用户线程(User Thread) .

而从狭义上讲,用户线程指的是完全建立在用户空间的线程库上,系统内核不能感知到线程存在.
用户线程的建立,同步,销毁和调度完全在用户态中完成,不需要内核的帮助.如果程序实现得当,这种线程不需要切换到内核态,因此操作可以是非常快速且低消耗的,也可以支持规模更大的线程数量.部分高性能数据库中的多线程就是由用户线程实现的.这种进程与用户线程之间1:N的关系成为一对多的线程模型.

使用用户线程的优势在于不需要系统内核支援,劣势也在于没有系统内核的支援,所有的线程操作都需要用户程序自己去处理.线程的创建,切换和调度都是需要考虑的问题,而且由于操作系统制霸处理器资源分配到进程,那诸如阻塞如何处理,多处理器系统之如何将线程映射到其他处理器上这类问题解决起来异常困难,甚至不可能完成.除了以前在不支持多线程的操作系统中(如DOS)的多线程程序与少数有特殊需求的程序外,现在使用用户线程的程序越来越少了,Java,Ruby等语言都曾经使用过用户线程,最终又都放弃使用它.

使用用户线程加轻量级进程混合实现

在这种混合实现下,既存在用户线程,也存在轻量级进程.用户线程还是完全建立在用户空间中,因此用户线程的创建,切换,析构等操作依然廉价,并且可以支持大规模的用户线程并发.而操作系统提供支持的轻量级进程则作为用户线程和内核线程之间的桥梁,这样可以使用内核提供的线程调度功能及处理器映射,并且用户线程的系统调用要通过轻量级线程来完成,大大降低了整个进程被完全阻塞的风险.
在这种混合模式下,用户线程与轻量级进程的数量比是不定的,即为N:M的关系

Java线程的实现

对于Sun JDK来说,它的Windows版与Linux版都是使用一对一的线程模型实现的,一条Java线程就映射到一条轻量级进程之中,因为Windows和Linux系统提供的线程模型是一对一的.

Java线程调度

线程调度是指系统为线程分配处理器使用权的过程,主要调度方式有两种,分别是 协同式线程调度(Cooperative Threads-Sheduling) 和 抢占式线程调度(Preemptive Threads-Sheduling)

如果使用协同式调度的多线程系统,线程的执行时间由线程本身来控制,线程把自己的工作执行完了之后,要主动通知系统切换到另外一个线程上.
协同式多线程的最大好处是是实现简单,而且由于线程要把自己的事情干完后才会进行线程切换,切换操作对线程自己是可知的,所以没有什么线程同步的问题.
它的最大坏处也很明显:线程执行时间不可控制,甚至如果出现一个线程编写有问题,一直不告知系统进行线程切换,那么程序就会一直阻塞在那里.

如果使用抢占式的多线程系统,那么每个线程将有系统来分配执行时间,线程的切换不由线程本身来决定(在Java中,Thread.yield()可以让出执行时间,但是要获取执行时间的话,线程本身是没什么办法的).在这种实现线程调度的方式下,线程的执行时间是系统可控的,也不会有一个线程导致整个进程阻塞的问题,Java使用的线程调度方式就是抢占式调度.

线程状态

新建(New)
创建后尚未启动的线程处于这种状态
运行(Runable)
Runable包括了操作系统线程转台中的Running和Ready,也就是处于此转台的线程有可能正在执行,也有可能正在等着CPU给它分配时间
无限期等待(Waiting)
处于这种转态的线程不会被分配CPU时间,它们要等待被其他线程显式地唤醒.以下方法会让线程进入无限期等待状态:
- 没有设置Timeout参数的Object.wait()方法
- 没有设置Timeout参数的Thread.join()方法
- LockSupport.park()方法
限期等待(Timed Waiting)
处于这种转态的线程不会被分配CPU执行时间,不过无须等待被其他线程显式地唤醒,在一定时间之后它们由系统自动唤醒.以下方法会让线程进入限期等待状态:
- Thread.sleep()方法
- 设置了Timeout参数的Object.wait()方法
- 设置了Timeout参数的Thread.join()方法
- LockSupport.parkNanos()方法
- LockSupport.parkUntil()方法
阻塞(Blocked)
线程被阻塞了,"阻塞转态"与"等待状态"的区别是:阻塞状态在等待着获取到一个排他锁,这个时间将在另外一个线程放弃这个锁的时候发生;而等待状态则是在等待与短时间,或者唤醒动作的发生.在线程等待进入同步区域的时候,线程将进入这种状态
结束(Terminated)
已终止线程的线程状态,线程已经结束执行

线程安全

当多个线程访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那么这个对象是线程安全的.
这个定义比较严谨,它要求线程安全的代码都具备一个特征:代码本身封装了所有必要的保障手段(如同步互斥等),令调用者无需关心多线程的问题,更无须自己采取任何措施来保证多线程的正确调用.

在大多数场景中,我们都会将这个定义弱化一些,如果把"调用这个对象的行为"限定为"单次调用",这个定义的其他描述也能够成立的话,我们就称它是线程安全的了.

Java中的线程安全

按照线程安全的"安全程度"由强至弱来排序,我们可以将Java语言中的各种操作共享的数据分为以下五类:不可变,绝对线程安全,相对线程安全,线程兼容和线程对立

不可变

不可变(Immutable) 对象一定是线程安全的,无论是对象的方法实现还是方法的调用者,都不需要再采取任何的线程安全保障措施,只要一个不可变的对象被正确地构建出来(没有发生this引用逃逸的情况),那其外部的可见状态永远也不会改变,永远也不会看到它在多个线程之中处于不一样的状态."不可变"带来的安全性是最简单最纯粹的.

Java语言中,如果共享数据是一个基本数据类型,那么只要在定义时使用final关键字修饰它就可以保证它是不可变的.如果共享数据是一个对象,那就要保证对象的行为不会对其状态产生任何影响才行.如java.lang.String的对象,它是一个典型的不可变对象,我们调用它的substring(),replace和concat()这些方法都不会影响它原来的值,只会返回一个新构造的字符串对象.

保证对象行为不影响自己状态的途径有很多种,其中最简单的就是把对象中带有状态的变量都声明为final,这样在构造函数结束之后,它就是不可变的.

绝对线程安全

绝对的线程安全满足上面严格的线程安全的定义,一个类要达到"不管运行时环境如何,调用者都不需要任何额外的同步措施"通常需要付出很大的,甚至有时候是不切实际的代价.在Java API中标注自己是线程安全的类,大多数都不是绝对的线程安全.

相对线程安全

相对的线程安全就是我们通常所讲的线程安全,它需要保证对这个对象单独操作是线程安全的,我们在调用的时候不需要额外的保障措施,但是对于一些特定顺序的连续调用,就可能需要在调用端使用额外的同步手段来保证调用的正确性.

在Java中,大部分的线程安全类都属于这种类型,如Vector,HashTable,Collection的synchronizeCollection()方法包装的集合等.

线程兼容

线程兼容是指对象本身并不是线程安全的,但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用.我们平常说一个类不是线程安全的,绝大多数时候指的都是这一种情况.
Java API中大部分的类都是属于线程兼容的.

线程对立

线程对立是指无论调用端是否采取了同步措施,都无法在多线程环境中并发使用的代码.
线程对立很少出现.

线程安全的实现方法

互斥同步

互斥同步(Mutual Exclusion & Synchronization)
同步是指在多个线程并发访问共享数据时,保证共享数据在同一个时刻只被一个(或者是一些,使用信号量的时候)线程使用.
而互斥是实现同步的一种手段,临界区(Critical Section) , 互斥量(Mutex) 和 信号量(Semaphore) 都是主要的互斥实现方式.

互斥是因,同步是果;互斥是方法,同步是目的.

Synchronized

在Java中,最常用的互斥同步手段就是synchronized关键字.
synchronized关键字经过变异之后,会在同步块前后分别行程 monitorenter 和 monitorexit这两个字节码指令

这两个字节码指令都需要一个reference类型的参数来指明要锁定的对象.
如果Java程序中的synchronized明确指定了对象,那就是这个对象的reference
如果没有明确指定,那就根据synchronized修饰的是实例方法还是类方法,去取对应的对应的对象实例或Class对象作为锁对象.

在执行monitorenter指令时,首先会尝试获取对象的锁,如果这个对象没被锁定,或者当前进程已经拥有了那个对象的锁,把锁的计数器加1
在执行monitorexit指令时会将锁计数器减1,当计数器为0时,锁就被释放.
如果获取对象锁失败,那当前线程就要阻塞等待,知道对象锁被另外一个线程释放为止.

虚拟机规范在堆monitorenter和monitorexit的行为描述中,有两点是需要注意的:
synchronized同步块对同一条线程来说是可重入的,不会出现自己把自己锁死的情况.
同步块在已进入线程执行完之前,会阻塞后面其他线程的进入.因Java的线程是映射到轻量级进程中的,如果需要阻塞或唤醒一个线程,都需要操作系统来帮忙完成,这就需要从用户态转换到核心态,因此状态需要消耗很多的处理器时间.所以synchronized是Java语言中一个重量级(Heavyweight)的操作.而虚拟机本身会进行优化,比如在通知操作系统阻塞进程之前加入一段自旋等待过程,避免频繁在用户态与内核态之间切换.

JUC

也可以通过JUC包中的 重入锁(ReentrantLock) 来实现同步.ReentrantLock与synchronized很相似,他们都具备一样的线程重入特性,只是代码写法上有点区别,一个表现为API层面的互斥锁,另一个表现为远胜于法层面的互斥锁.

ReentrantLock相比synchronized增加了一些高级功能,主要为以下三种:

等待可中断
当持有锁的线程长期不释放锁的时候,正在等待的线程可以选择放弃等待,改为处理其他事情,可中断特性对处理执行时间非常长的同步块很有帮助.
公平锁
公平锁是指多个线程在等待同一个锁的时候,必须按照申请锁的时间顺序来依次获得锁.而非公平锁在释放时,任何一个等待锁的线程都有机会获得锁.
锁绑定多个条件
一个ReentrantLock可以同时绑定多个Condition对象,而在synchronized中,锁对象的wait(),notify()或notifyAll()方法可以实现一个隐含的条件,如果要和多于一个的条件关联的时候,就不得不额外添加一个锁,而ReentrantLock则无需这样做,只需要多次调用newCondition()方法即可.

互斥同步最主要的问题就是进行线程阻塞和唤醒带来的性能问题.因此这种同步也成为阻塞同步(Blocking Synchronize).从处理问题的方式上说,互斥同步属于一种悲观的并发策略,总是认为只要不去加锁就肯定会出问题,无论共享数据是否真的会出现竞争,它都要进行加锁,用户态与核心态转换,维护锁计数器合集检查是否有阻塞的线程需要唤醒等操作.

非阻塞同步

非阻塞同步(Non-Blocking Synchronize) 是基于冲突检测的乐观并发策略,通俗地讲,就是先进行操作,如果没有其他线程征用共享数据,那操作就成功了,如果共享数据有征用,产生了冲突,那就再采取其他的补偿措施(最常见的补偿措施是不断重试,直至成功).这种乐观的策略不需要将线程挂起.

无同步方案

要保证线程安全,并不是一定就要进行同步.同步只是保证共享数据争用时的正确性手段,如果一个方法本来就不涉及共享数据,那么它自然就无须任何同步措施去保证正确性,因此会有一些代码天生就是线程安全的.

可重入代码

可重入代码(Reentrant Code) 这种代码也叫作纯代码(Pure Code) ,可以在代码执行的任何时刻中断它,转而去执行另外一段代码,而在控制权返回后,原来的程序不会出现任何错误.相对线程安全来说,可重入性是更基本的特性,它可以保证线程安全.

可重入代码有一些共同的特征,例如不依赖存储在堆上的数据和公用的系统资源,用到的状态都由参数传入,不调用非可重入的方法等.
我们可以通过一个简单的原则来判断代码是否具有可重入性:如果一个方法它的返回结果是可以预测的,只要输入了相同的数据,就都能返回相同的结果,那它就满足可重入性.

线程本地存储

线程本地存储(Thread Local Storage) 指的是,如果一段代码中所需要的数据必须与其他代码共享,那就看看这些共享数据的代码是否能保证在同一个线程中执行,如果能保证,我们就可以把共享数据的可见范围限制在同一个线程之内,这样,无须同步也能保证线程之间不出现数据争用的问题.

ThreadLocal

Java中的java.lang.ThreadLocal类就是来实现线程本地存储的.

锁优化

自旋锁与自适应自旋锁

互斥同步对性能最大的影响就是阻塞的实现,挂起线程和回复线程的操作都需要转入内核态中完成,这些操作给系统的并发性能带来了很大的压力.同时,共享数据的锁定状态只会持续很短的一段时间,为了这段时间去挂起和回复线程并不值得.

如果物理机器上有一个以上的处理器,能让两个或以上的线程同时并行执行,我们就可以让后面请求锁的线程稍等一下但不放弃处理器的执行时间(即以一些CPU资源为代价,换来的是省去了内核态与用户态的切换),看看持有锁的线程是否很快就会释放锁.为了让线程等待,我们只需让线程执行一个忙循环(自旋),这项技术就是自旋锁.

自旋等待本身虽然避免了线程切换的开销,但它是要占用处理器时间的,因此,如果锁被占用的时间很短,自旋等待的效果就会非常好,反之,如果锁被占用的时间很长,那么自旋的线程只会白白消耗处理器资源,而不会做任何有用的工作,反而会带来性能上的浪费.
因此,自旋等待的时间必须要有一定的限度,如果自旋超过了限定的次数仍然没有成功获得锁,就应当使用传统的阻塞式的方式去挂起线程了.

自适应的自旋锁意味着自旋的时间不再固定了,而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定. 如果在同一个锁对象上,自旋等待刚刚成功获得过锁,并且持有锁的线程正在运行中,那么虚拟机就会认为这次自旋也很有可能再次成功,进而它将允许自旋等待持续相对更长的时间.

锁清除

锁清除是指虚拟机即时编译在运行时,对一些代码上要求同步,但是被检测到不可能存在共享数据竞争的锁进行消除.锁清除的主要判断依据来源于逃逸分析的数据支持,如果判断在一段代码中,堆上的所有数据都不会逃逸出去从而被其他线程访问到,那就把他们当做线上数据对待,认为它们是线程私有的,同步加锁自然就无须进行.

锁粗化

如果一系列的连续操作都对同一个对线反复加锁和解锁,那即使没有线程竞争,频繁地进行互斥同步操作也会导致不必要的性能损耗.

例如:

public String concatString(String s1, String s1, String s3){
    StringBuilder sb = new StringBuilder();
    sb.append(s1);
    sb.append(s2);
    sb.append(s3);
    return sb.toString():
}

如果JVM探测到这样的一连串对同一个对象(sb)加锁的操作,将会把加锁同步的范围扩展(粗化)到整个操作序列的外部.

轻量级锁

操作系统互斥量来实现的传统锁被称为重量级锁,而轻量级锁是相对于重量级锁来讲的.
轻量级锁并不是用来代替重量级锁的,它的本意是在没有多线程竞争的前提下,减少传统的重量级锁使用操作系统互斥量产生的性能消耗.

对象头中有2bit用来存储锁标志位,

黄瓜养殖基地！