Java并发编程系列-(7) Java线程安全
后端精进之路 人气:0
7. 线程安全
7.1 线程安全的定义
如果多线程下使用这个类，不过多线程如何使用和调度这个类，这个类总是表示出正确的行为，这个类就是线程安全的。
类的线程安全表现为：
- 操作的原子性
- 内存的可见性
不做正确的同步，在多个线程之间共享状态的时候，就会出现线程不安全。
7.2 如何保证线程安全
栈封闭
所有的变量都是在方法内部声明的，这些变量都处于栈封闭状态。
比如下面的例子,a和b都是在方法内部定义的，无法被外部线程所访问，当方法结束后，栈内存被回收，所以是线程安全的。
void fun（）{
int a = 1；
int b= 2；
// do something
}无状态
没有任何成员变量的类，就叫无状态的类，这种类不存在共享的资源，显然是安全的。
public class StatelessClass {
public int service(int a,int b) {
return a*b;
}
}不可变的类
让状态不可变，两种方式：
- 加final关键字。对于一个类，所有的成员变量应该是私有的，并且可能的情况下，所有的成员变量应该加上final关键字。需要注意如果成员变量又是一个对象时，这个对象所对应的类也要是不可变，才能保证整个类是不可变的。
- 根本就不提供任何可供修改成员变量的地方，同时成员变量也不作为方法的返回值。
下面例子中的，成员变量都是final并且也没有提供给外部修改变量的地方，因此是线程安全的。
public class ImmutableFinal {
private final int a;
private final int b;
public ImmutableFinal(int a, int b) {
super();
this.a = a;
this.b = b;
}
public int getA() {
return a;
}
public int getB() {
return b;
}
}下面的例子中，虽然User成员变量是final的，无法修改引用。但是外部依然可以通过getUser获取到User的引用之后，修改User对象。
public class ImmutableFinalRef {
private final int a;
private final int b;
private final User user;//这里就不能保证线程安全了
public ImmutableFinalRef(int a, int b) {
super();
this.a = a;
this.b = b;
this.user = new User();
}
public int getA() {
return a;
}
public int getB() {
return b;
}
public User getUser() {
return user;
}
public static class User{
private int age;
public User(int age) {
super();
this.age = age;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
public static void main(String[] args) {
ImmutableFinalRef ref = new ImmutableFinalRef(12,23);
User u = ref.getUser();
//u.setAge(35);
}
}volatile
volitile在ConcurrentHashMap等并发容器中都有使用，用于保证变量的可见性。最适合一个线程写，多个线程读的情景。
加锁和CAS
加锁可以显示地控制线程对类的访问，使用正确可以保证线程安全。
CAS操作通过不断的循环对比，试图对目标对象进行修改，也能保证线程安全。广泛用于JDK并发容器的实现中。
安全的发布
类中持有的成员变量，特别是对象的引用，如果这个成员对象不是线程安全的，通过get等方法发布出去，会造成这个成员对象本身持有的数据在多线程下不正确的修改，从而造成整个类线程不安全的问题。
ThreadLocal
这个类能使线程中的某个值与保存值的对象关联起来。ThreadLocal提供了get与set等访问接口与方法，这些方法为使用该变量的每个线程都存有一份独立的副本，因此get总是返回由当前执行线程在调用set时设置的最新值。
当某个线程初次调用ThreadLocal.get方法时，就会调用initialValue来获取初始值。从概念上讲，你可以将ThreadLocal
7.3 死锁
定义
死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁。
死锁的根本成因：获取锁的顺序不一致导致。
可以利用下面的示意图帮助理解：
死锁范例
下面的程序中，两个线程分别获取到了first和second，然后相互等待，产生了死锁。
public class DeadLockSample extends Thread {
private String first;
private String second;
public DeadLockSample(String name, String first, String second) {
super(name);
this.first = first;
this.second = second;
}
public void run() {
synchronized (first) {
System.out.println(this.getName() + " obtained: " + first);
try {
Thread.sleep(1000L);
synchronized(second) {
System.out.println(this.getName() + " obtained: " + second);
}
} catch (InterruptedException e) {
// Do nothing
}
}
}
public static void main(String[] args) throws InterruptedException {
String lockA = "lockA";
String lockB = "lockB";
DeadLockSample t1 = new DeadLockSample("Thread1", lockA, lockB);
DeadLockSample t2 = new DeadLockSample("Thread2", lockB, lockA);
t1.start();
t2.start();
t1.join();
t2.join();
}
}
定位和解决死锁
Debug时可以使用 jps 或者系统的 ps 命令、任务管理器等工具，确定进程 ID。其次，调用 jstack 获取线程栈，jstack your_pid. jstack 本身也会把类似的简单死锁抽取出来，直接打印出来。
如果是开发自己的管理工具，需要用更加程序化的方式扫描服务进程、定位死锁，可以考虑使用 Java 提供的标准管理 API，ThreadMXBean，其直接就提供 findDeadlockedThreads() 方法用于定位，上面的例子中用到了这个方法。
怎么预防死锁？
如果可能的话，尽量避免使用多个锁，并且只有需要时才持有锁。
如果必须使用多个锁，尽量设计好锁的获取顺序。如果对于两个线程的情况，可以参考如下的实现：
在实现转账的类时，为了防止由于相互转账导致的死锁，下面的实现中，通过对比账户的hash值来确定获取锁的顺序。当两者的hash值相等时，虽然这种情况非常少见，使用了单独的锁，来控制两个线程的访问顺序。
注意System.identityHashCode()是JDK自带的hash实现，在绝大部分情况下，保证了对象hash值的唯一性。
public class SafeOperate implements ITransfer {
private static Object tieLock = new Object();//加时赛锁
@Override
public void transfer(UserAccount from, UserAccount to, int amount)
throws InterruptedException {
int fromHash = System.identityHashCode(from);
int toHash = System.identityHashCode(to);
//先锁hash小的那个
if(fromHash<toHash) {
synchronized (from){
synchronized (to){
System.out.println(Thread.currentThread().getName()
+" get"+to.getName());
from.flyMoney(amount);
to.addMoney(amount);
}
}
}else if(toHash<fromHash) {
synchronized (to){
Thread.sleep(100);
synchronized (from){
from.flyMoney(amount);
to.addMoney(amount);
}
}
}else {//解决hash冲突的方法
synchronized (tieLock) {
synchronized (from) {
synchronized (to) {
from.flyMoney(amount);
to.addMoney(amount);
}
}
}
}
}
}- 使用带超时的方法，为程序带来更多可控性。
类似 Object.wait(…) 或者 CountDownLatch.await(…)，都支持所谓的 timed_wait，我们完全可以就不假定该锁一定会获得，指定超时时间，并为无法得到锁时准备退出逻辑。
- 使用Lock实现（推荐）
并发 Lock 实现，如 ReentrantLock 还支持非阻塞式的获取锁操作 tryLock()，这是一个插队行为（barging），并不在乎等待的公平性，如果执行时对象恰好没有被独占，则直接获取锁。
标准的使用流程如下：
while(true) {
if(A.getLock().tryLock()) {
try {
if(B.getLock().tryLock()) {
try {
//两把锁都拿到了，开始执行业务代码
break;
}finally {
B.getLock().unlock();
}
}
}finally {
A.getLock().unlock();
}
}
// 非常重要，sleep随机的时间，以防两个线程谦让，产生长时间的等待，也就是活锁
SleepTools.ms(r.nextInt(10));
}7.4 活锁/线程饥饿/无锁
活锁
活锁恰恰与死锁相反，死锁是大家都拿不到资源都占用着对方的资源，而活锁是拿到资源却又相互释放不执行。当多线程中出现了相互谦让，都主动将资源释放给别的线程使用，这样这个资源在多个线程之间跳动而又得不到执行，这就是活锁。
在上面解决死锁的第四个方案中，为了避免活锁，采用了随机休眠的机制。
线程饥饿
线程执行中有线程优先级，优先级高的线程能够插队并优先执行，这样如果优先级高的线程一直抢占优先级低线程的资源，导致低优先级线程无法得到执行，这就是饥饿。当然还有一种饥饿的情况，一个线程一直占着一个资源不放而导致其他线程得不到执行，与死锁不同的是饥饿在以后一段时间内还是能够得到执行的，如那个占用资源的线程结束了并释放了资源。
无锁
对于并发控制而言，锁是一种悲观的策略，它总是假设每一次的临界区操作会产生冲突，由此，如果有多个线程同时需要访问临界区资源，则宁可牺牲资源让线程进行等待。
无锁是一种乐观的策略，它假设对资源的访问是没有冲突的。既然没有冲突，自然不需要等待，所以所有的线程都可以在不停顿地状态下持续执行。当遇到冲突，则使用CAS来检测线程冲突，如果发现冲突，则重试直到没有冲突为止。
CAS算法的过程是，它包含三个参数CAS（V，E，N），V表示要更新的变量，E表示预期值，N表示新值。仅当V值等于E值时，才将V的值设置为N，如果V值和E值不同，说明已经有其他线程做了更新，则当前线程什么都不做。使用CAS操作一个变量时，只有一个会胜出，并成功更新，其余均会失败。
7.5 影响性能的因素
- 上下文切换：一般花费5000-10000个时钟周期，几微秒
- 内存同步：加锁等操作，增加额外的指令执行时间
- 阻塞：挂起线程，包括额外的上下文切换
7.6 锁性能优化
减少锁的持有时间
减少锁的持有时间有助于降低锁冲突的可能性,进而提升系统的并发能力。
减小锁粒度
这种技术的典型使用场景就是ConcurrentHashMap。
对于HashMap来说,最重要的两个方法就是get() 和put(),一种最自然的想法就是对整个HashMap加锁,必然可以得到一个线程安全的对象.但是这样做,我们就认为加锁粒度太大.对于ConcurrentHashMap,它内部进一步细分了若干个小的hashMap,称之为段(SEGMENT).默认的情况下,一个ConcurrentHashMap被进一步细分为16个段
如果需要在ConcurrentHashMap中增加一个新的表项,并不是整个HashMap加锁,而是首先根据hashcode得到该表项应该被存放到哪个段中,然后对该段加锁,并完成put()操作.在多线程环境中,如果多个线程同时进行put()操作,只要被加入的表项不存放在同一个段中,则线程间便可以做到真正的并行。
读写分离锁来替换独占锁
在读多写少的场合,使用读写锁可以有效提升系统的并发能力
锁分离
如果将读写锁的思想进一步的延伸,就是锁分离.读写锁根据读写锁操作功能上的不同,进行了有效的锁分离.使用类似的思想,也可以对独占锁进行分离.
以LinkedBlockingQueue为例,take函数和put函数分别实现了冲队列取和往队列加数据，虽然两个方法都对队列进项了修改，但是LinkedBlockingQueue是基于链表的所以一个操作的是头，一个是队列尾端，从理论情况下将并不冲突
如果使用独占锁则take和put就不能完成真正的并发，所以jdk并没有才用这种方式取而代之的是两把不同的锁分离了put和take的操作
锁粗化
凡事都有一个度,如果对同一个锁不停地进行请求,同步和释放,其本身也会消耗系统宝贵的资源,反而不利于性能的优化。
为此,虚拟机在遇到一连串连续地对同一锁不断进行请求和释放的操作时,便会把所有的锁操作整合成对锁的一次请求,从而减少对锁的请求同步次数,这个操作叫做锁的粗化.
7.7 实现线程安全的单例模式
懒汉式
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}线程安全，并且解决了多实例的问题，但是它并不高效。因为在任何时候只能有一个线程调用 getInstance() 方法。
双重检验锁
public class Singleton {
private static volatile Singleton singleton = null;
private Singleton() {
}
public static Singleton getSingleton() {
if (singleton == null) { // 尽量避免重复进入同步块
synchronized (Singleton.class) { // 同步.class，意味着对同步类方法调用
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}- volatile 能够提供可见性，以及保证 getInstance 返回的是初始化完全的对象。
- 在同步之前进行 null 检查，以尽量避免进入相对昂贵的同步块。
- 直接在 class 级别进行同步，保证线程安全的类方法调用。
在这段代码中，争论较多的是 volatile 修饰静态变量，当 Singleton 类本身有多个成员变量时，需要保证初始化过程完成后，才能被 get 到。 在现代 Java 中，内存排序模型（JMM）已经非常完善，通过 volatile 的 write 或者 read，能保证所谓的 happen-before，也就是避免常被提到的指令重排。换句话说，构造对象的 store 指令能够被保证一定在 volatile read 之前。
饿汉式
这种方法非常简单，因为单例的实例被声明成 static 和 final 变量了，在第一次加载类到内存中时就会初始化，所以创建实例本身是线程安全的。
public class Singleton{
//类加载时就初始化
private static final Singleton instance = new Singleton();
private Singleton(){}
public static Singleton getInstance(){
return instance;
}
}静态内部类(推荐)
public class Singleton {
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton (){}
public static final Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}静态内部类是在被调用时才会被加载，因此它是懒汉式的。
本文由『后端精进之路』原创，首发于博客 http://teckee.github.io/ , 转载请注明出处
搜索『后端精进之路』关注公众号，立刻获取最新文章和价值2000元的BATJ精品面试课程。
加载全部内容