文档章节
一、什么是类的线程安全
既然今天的主题是线程安全，那什么是线程安全呢？
其实线程安全并没有一个明确的定义，Doug Lea大师(不认识的去百度，java不认识的去面壁)给下的定义为多线程下使用这个类，不过多线程如何使用和调度这个类，这个类总是表示出正确的行为，这个类就是线程安全的。
类的线程安全表现为：
- 操作的原子性
- 内存的可见性
不做正确的同步，在多个线程之间共享状态的时候，就会出现线程不安全。
1、操作的原子性
原子性在之前的篇章都有讲过，就不细说了。主要就是表示一个操作是不可中断的，或者不可在分割的，要么全部执行成功要么全部执行失败。
2、内存的可见性
多个线程对同一个变量（称为：共享变量）进行操作，但是这多个线程有可能被分配到多个处理器中运行，那么编译器会对代码进行优化，当线程要处理该变量时，多个处理器会将变量从主存复制一份分别存储在自己的存储器中，等到进行完操作后，再赋值回主存。
这样做的好处是提高了运行的速度，同样优化带来的问题之一是变量可见性——如果线程t1与线程t2分别被安排在了不同的处理器上面，那么t1与t2对于变量A的修改时相互不可见，如果t1给A赋值，然后t2又赋新值，那么t2的操作就将t1的操作覆盖掉了，这样会产生不可预料的结果。因此，需要保证变量的可见性（一个线程对共享变量值的修改，能够及时地被其它线程看到）。
多线程操作共享变量实现可见性过程JVM的内存模型如下：
![]()
因此，如果要保证线程安全，那就要保证，我们所有的线程读取到的共享变量都是正确的值，也就是保证内存的可见性。
二、让类的做到线程安全的方式
2.1、栈封闭
如果了解JVM的同学应该都清楚，java中定义的每个方法，存储在java的方法栈中，每个方法是一个栈桢，所谓的栈封闭，就是变量在方法内部进行声明。那么这些变量都是处于栈封闭状态的。（说简单点就是定义局部变量）
code：
/**
* @Auther: DarkKing
* @Date: 2019/5/12 12:09
* @Description:栈封闭
*/
public class WorkTask {
//不安全
private String name;
public Integer call() {
//方法内的成员变量是安全的，
String name ="safe";
this.name = name;
int sleepTime = new Random().nextInt(1000);
try {
Thread.sleep(sleepTime);
} catch (InterruptedException e) {
e.printStackTrace();
}
return sleepTime;
}
}
2.2、无状态
就是没有实例变量的对象 ，没有具体字段，不能保存数据，是不变类。例如我们MVC模式中的DAO层。只定义方法，没有定义字段变量。
/**
* @Auther: DarkKing
* @Date: 2019/5/12 12:09
* @Description:没有任何变量，线程安全
*/
public class WorkTask {
public Integer call() {
String name ="safe";
int sleepTime = new Random().nextInt(1000);
try {
Thread.sleep(sleepTime);
} catch (InterruptedException e) {
e.printStackTrace();
}
return sleepTime;
}
}
2.3、让类不可变
除了将类定义成无状态之外，但大多数情况下，我们的类都是有字段的，有状态的，那就需要通过让类不可变的方式，让类变得安全。方式有以下两种
(1)，加final关键字，但是加上final，要注意如果成员变量又是一个对象时，这个对象所对应的类也要是不可变，才能保证整个类是不可变的。
code:
package com.xiangxue.ch7.safeclass;
/**
* @Auther: DarkKing
* @Date: 2019/5/12 12:09
* @Description: 不可变的类
*/
public class ImmutableFinalRef {
//因为a，b都是final变量，不可变，顾属于安全的。
private final int a;
private final int b;
//这里，就不能保证线程安全啦，因为user是一个引用类型，user对象里的字段有可能进行改变，
//除非user对象里所有字段也都是final类型，否则User其实是可变的。
private final User user;
public ImmutableFinalRef(int a, int b) {
super();
this.a = a;
this.b = b;
this.user = new User(2);
}
public int getA() {
return a;
}
public int getB() {
return b;
}
public User getUser() {
return user;
}
//将User内部所有字段改为final，则能保证改类为线程安全。
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();
}
}
(2)、根本就不提供任何可供修改成员变量的地方，同时成员变量也不作为方法的返回值
code：
/**
* @Auther: DarkKing
* @Date: 2019/5/12 12:09
* @Description:不可变的类
*/
public class ImmutetableToo {
//改类也属于线程安全的，因为没有提供任何获取和修改的地方。
private List<Integer> list = new ArrayList<>(3);
public ImmutetableToo() {
list.add(1);
list.add(2);
list.add(3);
}
public boolean isContains(int i) {
return list.contains(i);
}
}
java开发建议:对于一个类，所有的成员变量应该是私有的，如果有可能，所有的成员变量应该加上final关键字.可以保证线程安全。
2.4、volatile
volatile关键字可以保证保证类的可见性，最适合一个线程写，多个线程读的情景，
2.5、加锁和CAS
恩，这个没啥好解释的了。。。。
2.6、安全的发布
类中持有的成员变量，特别是对象的引用，如果这个成员对象不是线程安全的，通过get等方法发布出去，会造成这个成员对象本身持有的数据在多线程下不正确的修改，从而造成整个类线程不安全的问题。
/**
* @Auther: DarkKing
* @Date: 2019/5/12 12:09
* @Description:存在不安全的发布
*/
public class UnsafePublish {
//要么用线程安全的容器替换
//要么发布出去的时候，提供副本，深度拷贝
private List<Integer> list = new ArrayList<>(3);
public UnsafePublish() {
list.add(1);
list.add(2);
list.add(3);
}
//将list不安全的发布出去了，线程不安全。
public List<Integer> getList() {
return list;
}
//也是安全的,加了锁--------------------------------
public synchronized int getList(int index) {
return list.get(index);
}
public synchronized void set(int index,int val) {
list.set(index,val);
}
}
2.7、TheadLocal
ThreadLocal的实例代表了一个线程局部的变量，每条线程都只能看到自己的值，并不会意识到其它的线程中也存在该变量。
三、线程安全引发的一些问题
3.1、死锁
死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。
发生死锁的条件是，竞争资源一定是多于1个，同时小于等于竞争的线程数，当资源只有一个，只会产生激烈的竞争，不会死锁。
死锁的根本成因：获取锁的顺序不一致导致。
code：
/**
* @Auther: DarkKing
* @Date: 2019/5/12 12:09
* @Description:死锁的例子
*/
public class NormalDeadLock {
private static Object lockFirst = new Object();//第一个锁
private static Object lockSecond = new Object();//第二个锁
//先拿第一个锁，再拿第二个锁
private static void fisrtToSecond() throws InterruptedException {
String threadName = Thread.currentThread().getName();
synchronized (lockFirst) {
System.out.println(threadName+" get first");
SleepTools.ms(100);
synchronized (lockSecond) {
System.out.println(threadName+" get second");
}
}
}
//先拿第二个锁，再拿第一个锁
private static void SecondToFisrt() throws InterruptedException {
String threadName = Thread.currentThread().getName();
synchronized (lockFirst) {
System.out.println(threadName+" get first");
SleepTools.ms(100);
synchronized (lockSecond) {
System.out.println(threadName+" get second");
}
}
}
//执行先拿第二个锁，再拿第一个锁
private static class TestThread extends Thread{
private String name;
public TestThread(String name) {
this.name = name;
}
public void run(){
Thread.currentThread().setName(name);
try {
SecondToFisrt();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) {
Thread.currentThread().setName("TestDeadLock");
TestThread testThread = new TestThread("SubTestThread");
testThread.start();
try {
fisrtToSecond();//先拿第一个锁，再拿第二个锁
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
3.1.1查找程序是否死锁的方式
1、代码逻辑查看
2、通过通过jps 查询应用的 id，再通过jstack id 查看应用的锁的持有情况，高版本的JDK可以直接检测到简单地死锁
![]()
![]()
![]()
解决办法：保证加锁的顺序性
3.1.2动态的死锁
动态顺序死锁，在实现时按照某种顺序加锁了，但是因为外部调用的问题，导致无法保证加锁顺序而产生的。
code:
/**
* @Auther: DarkKing
* @Date: 2019/5/12 12:09
* @Description:不安全的转账动作的实现
*/
public class TrasnferAccount implements ITransfer {
//当根据传参不一致，有可能会导致死锁。
//一个线程先锁了from，在锁了to同时另一个线程将to当做from传参，
// 将from当做to传参。那么第二个线程则先锁了to，又锁了from。导致死锁
@Override
public void transfer(UserAccount from, UserAccount to, int amount)
throws InterruptedException {
synchronized (from){//先锁转出
System.out.println(Thread.currentThread().getName()
+" get"+from.getName());
Thread.sleep(100);
synchronized (to){//再锁转入
System.out.println(Thread.currentThread().getName()
+" get"+to.getName());
from.flyMoney(amount);
to.addMoney(amount);
}
}
}
}
解决：
- 通过内在排序，保证加锁的顺序性
- 通过尝试拿锁，也可以。
3.2、活锁
例如我们生活中的例子，两个人在窄路相遇，同时向一个方向避让，然后又向另一个方向避让，如此反复。导致两个人都过不去。
活锁即是在尝试拿锁的机制中，发生多个线程之间互相谦让，不断发生拿锁，释放锁的过程。
解决办法：每个线程休眠随机数，错开拿锁的时间。
3.3、线程饥饿
低优先级的线程，总是拿不到执行时间。
3.4、性能和思考
使用并发的目标是为了提高性能，引入多线程后，其实会引入额外的开销，如线程之间的协调、增加的上下文切换，线程的创建和销毁，线程的调度等等。过度的使用和不恰当的使用，会导致多线程程序甚至比单线程还要低。
衡量应用的程序的性能：服务时间，延迟时间，吞吐量，可伸缩性等等，其中服务时间，延迟时间（多快），吞吐量（处理能力的指标，完成工作的多少）。多快和多少，完全独立，甚至是相互矛盾的。
对服务器应用来说：多少（可伸缩性，吞吐量）这个方面比多快更受重视，先保证可以横向扩展，在保证垂直扩展。
我们做应用的时候：
- 先保证程序正确，确实达不到要求的时候，再提高速度。（黄金原则）
- 一定要以测试为基准。
一个应用程序里，串行的部分是永远都有的。
Amdahl定律 ： 1/(F+(1-N)/N) F:必须被串行部分,程序最好的结果为 1/F。
3.5、影响性能的因素
3.5.1、上下文切换
是指CPU 从一个进程或线程切换到另一个进程或线程。一次上下文切换花费5000~10000个时钟周期，几微秒。在上下文切换过程中，CPU会停止处理当前运行的程序，并保存当前程序运行的具体位置以便之后继续运行。从这个角度来看，上下文切换有点像我们同时阅读几本书，在来回切换书本的同时我们需要记住每本书当前读到的页码。
上下文切换通常是计算密集型的。也就是说，它需要相当可观的处理器时间。所以，上下文切换对系统来说意味着消耗大量的 CPU 时间，事实上，可能是操作系统中时间消耗最大的操作。
3.5.2、内存同步
一般指加锁，对加锁来说，需要增加额外的指令，这些指令都需要刷新缓存等等操作。
3.5.3、阻塞
会导致线程挂起【挂起：挂起进程在操作系统中可以定义为暂时被淘汰出内存的进程，机器的资源是有限的，在资源不足的情况下，操作系统对在内存中的程序进行合理的安排，其中有的进程被暂时调离出内存，当条件允许的时候，会被操作系统再次调回内存，重新进入等待被执行的状态即就绪态，系统在超过一定的时间没有任何动作】。很明显这个操作包括两次额外的上下文切换。
3.6、如何减少锁的竞争
3.6.1、减少锁的粒度
使用锁的时候，锁所保护的对象是多个，当这些多个对象其实是独立变化的时候，不如用多个锁来一一保护这些对象。但是如果有同时要持有多个锁的业务方法，要注意避免发生死锁
code
/**
* @Auther: DarkKing
* @Date: 2019/5/12 12:09
* @Description:
*/
public class FinenessLock {
public final Set<String> users = new HashSet<String>();
// 锁的粒度过大，在执行方法体是就进行加锁
// public void synchronized addUser(String u) {
// System.out.println("test");
// users.add(u);
// }
//只针对对操作的对象进行加锁，如果方法体重还有其他方法，则不影响其他业务进行。
public void addUser(String u) {
System.out.println("test");
synchronized (users) {
users.add(u);
}
}
}
加锁原则，能加锁对象别锁方法，能锁方法不要锁类。锁类尽量不要使用
3.6.2、缩小锁的范围
对锁的持有实现快进快出，尽量缩短持由锁的的时间。将一些与锁无关的代码移出锁的范围，特别是一些耗时，可能阻塞的操作
code:
/**
* @Auther: DarkKing
* @Date: 2019/5/12 12:09
* @Description:缩小锁的范围
*/
public class ReduceLock {
private Map<String,String> matchMap = new HashMap<>();
//加锁体力过多无关线程安全的操作
public boolean isMatch(String name,String regexp) {
synchronized(this){
String key = "user."+name;
String job = matchMap.get(key);
if(job == null) {
return false;
}else {
return Pattern.matches(regexp, job);//很耗费时间
}
}
}
//只对有可能发生线程安全问题的操作进行加锁
public boolean isMatchReduce(String name,String regexp) {
String key = "user."+name;
String job ;
synchronized(this) {
job = matchMap.get(key);
}
if(job == null) {
return false;
}else {
return Pattern.matches(regexp, job);
}
}
}
3.6.3、避免多余的缩减锁的范围
两次加锁之间的语句非常简单，导致加锁的时间比执行这些语句还长，这个时候应该进行锁粗化—扩大锁的范围。
3.6.4、锁分段
ConcurrrentHashMap就是典型的锁分段。下一篇会进行ConcurrrentHashMap源码进行分析。
3.6.5、替换独占锁
在业务允许的情况下：
- 使用读写锁，
- 用自旋CAS
- 使用系统的并发容器
本章重点,了解什么是线程安全，实现类线程安全的几种方式，线程安全可能会引发什问题以及性能瓶颈如何去解决和优化。下一章将会对java里的一些并发容器介绍，以及源码进行分析。
今天送波福利电子书，大家有兴趣可以下载哦。
链接：https://pan.baidu.com/s/1oTHGDw-7_A8Yhn5MzpuDNA
提取码：g5h1
其他阅读 并发编程专题
有什么问题可以留言或者扫下方二维码，加我微信进行沟通哦。
![481021518c4b8fa00ba60ef9609c53b2b5f.jpg]()
