7. Thread Safety
7.1 thread-safe definition
If you use this class multi-threaded, multi-threaded, but how to use and schedule the class, which always shows the correct behavior, this class is thread-safe.
Thread-safe performance class as follows:
- Atomic operation
- Visibility memory
Do not do proper synchronization, when the shared state between multiple threads, the thread will appear unsafe.
7.2 How to ensure the security thread
Stack closed
All variables are declared inside the method, these variables are in the stack closed.
For example the following example, a and b are defined within the method, can not be accessed by an external thread, the method ends when the stack memory is recovered, it is thread safe.
void fun（）{
int a = 1；
int b= 2；
// do something
}no status
No class member variable called stateless class, this class does not exist shared resources, it is clearly safe.
public class StatelessClass {
public int service(int a,int b) {
return a*b;
}
}Immutable class
Let immutable state, in two ways:
- Plus final keyword. For a class, all member variables should be private, and where possible, all member variables should be added to the final keyword . Note that if the member is a variable object, the object corresponding class will have to be immutable , in order to ensure that the entire class is immutable.
- It did not provide any places to modify member variables, member variables at the same time as the method does not return a value.
In the example below, member variables are final and there is no place available to modify external variables and is therefore thread-safe.
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;
}
}The following examples, although User member variable is final and can not be modified reference. But after the outer can still get a reference to the User by getUser, modify the User object.
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 are used for concurrent vessel to ensure the visibility of the variable. The most suitable for a write thread, multiple threads read the scene.
Locking and CAS
Display lock can control access to the thread of the class, using the correct thread-safety can be guaranteed.
CAS operated by Robin continued to try to modify the target audience, but also to ensure thread safety. JDK is widely used to implement concurrent container.
Safe release
类中持有的成员变量，特别是对象的引用，如果这个成员对象不是线程安全的，通过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精品面试课程。
