多线程线程安全_JAVA

多线程同步

当多个线程共享同一个资源,不会受到其他线程的干扰。

线程安全问题

当多个线程同时共享同一个全局变量或静态变量，做写的操作时，可能会发生数据冲突问题。

解决办法

使用多线程之间同步synchronized或使用锁(lock)。
将可能会发生数据冲突问题(线程不安全问题)，只能让当前一个线程进行执行；代码执行完成后释放锁，然后才能让其他线程进行执行。

内置的锁

Java提供了一种内置的锁机制来支持原子性。
每一个Java对象都可以用作一个实现同步的锁，称为内置锁，线程进入同步代码块之前自动获取到锁，代码块执行完成正常退出或代码块中抛出异常退出时会释放掉锁。

内置锁为互斥锁，使用synchronized关键字实现，synchronized关键字的两种用法：

1. 修饰需要进行同步的方法（所有访问状态变量的方法都必须进行同步），此时充当锁的对象为调用同步方法的对象。
2. 同步代码块和直接使用synchronized修饰需要同步的方法是一样的，但是锁的粒度可以更细，并且充当锁的对象不一定是this，也可以是其它对象，所以使用起来更加灵活。

同步代码块

就是将可能会发生线程安全问题的代码给括起来。

synchronized(同一个数据/对象){
 	//可能会发生线程冲突问题
}

对象如同锁，持有锁的线程可以在同步中执行 ；没持有锁的线程即使获取CPU的执行权，也进不去。
同步的前提：

1. 必须要有两个或者两个以上的线程
2. 必须是多个线程使用同一个锁

必须保证同步中只能有一个线程在运行
好处：解决了多线程的安全问题。
弊端：多个线程需要判断锁，较为消耗资源、抢锁的资源。

同步方法

在方法上修饰synchronized关键字。
同步方法使用this锁（证明方式: 一个线程使用同步代码块(this明锁)，另一个线程使用同步方法，如果两个线程不能实现同步，那么会出现数据错误）

静态同步方法

方法上加上static关键字修饰，使用synchronized 关键字修饰 或者使用类.class文件。
静态的同步方法使用的锁是该函数所属字节码文件对象。可以用 getClass方法获取，也可以用当前类名.class 表示。

多线程死锁

同步中嵌套同步,导致锁无法释放。

ThreadLocal

用于访问某个线程拥有自己的局部变量。
当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。

ThreadLocal的接口方法：

1. void set(Object value)设置当前线程的线程局部变量的值。
2. public Object get()该方法返回当前线程所对应的线程局部变量。
3. public void remove()将当前线程局部变量的值删除，目的是为了减少内存的占用，该方法是JDK 5.0新增的方法。需要指出的是，当线程结束后，对应该线程的局部变量将自动被垃圾回收，所以显式调用该方法清除线程的局部变量并不是必须的操作，但它可以加快内存回收的速度。
4. protected Object initialValue()返回该线程局部变量的初始值，该方法是一个protected的方法，显然是为了让子类覆盖而设计的。这个方法是一个延迟调用方法，在线程第1次调用get()或set(Object)时才执行，并且仅执行1次。ThreadLocal中的缺省实现直接返回一个null。

实现原理：通过map集合，Map.put(“当前线程”,值)

多线程三大特性

1. 原子性(即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。就是保证数据一致、线程安全一部分)
2. 可见性(当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值)
3. 有序性(程序执行的顺序按照代码的先后顺序执行；一般来说处理器为了提高程序运行效率，可能会对输入代码进行优化，因为重排序它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。重排序对单线程运行是不会有任何问题，而多线程就不一定了)

JAVA内存模型

共享内存模型指的就是Java内存模型(简称JMM)，JMM决定一个线程对共享变量的写入时，能对另一个线程可见。
从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。
图示：

线程A与线程B之间如要通信的话，必须要经历下面2个步骤：

1. 线程A把本地内存A中更新过的共享变量刷新到主内存中去。
2. 线程B到主内存中去读取线程A之前已更新过的共享变量。

volatile

volatile关键字的作用是变量在多个线程之间可见，强制线程每次读取该值的时候都去“主内存”中取值。
volatile保证了线程间共享变量的及时可见性，但不能保证原子性。

可见性也就是说一旦某个线程修改了该被volatile修饰的变量，它会保证修改的值会立即被更新到主存，当有其他线程需要读取时，可以立即获取修改之后的值。
在Java中为了加快程序的运行效率，对一些变量的操作通常是在该线程的寄存器或是CPU缓存上进行的，之后才会同步到主存中，而加了volatile修饰符的变量则是直接读写主存。

使用AtomicInteger原子类，它是一个提供原子操作的Integer类，通过线程安全的方式操作加减。

volatile特性

1. 保证此变量对所有的线程的可见性。
2. 禁止指令重排序优化。有volatile修饰的变量，赋值后多执行了一个“load addl $0x0, (%esp)”操作，这个操作相当于一个内存屏障（指令重排序时不能把后面的指令重排序到内存屏障之前的位置），只有一个CPU访问内存时，并不需要内存屏障；（什么是指令重排序：是指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理）。

volatile 的读性能消耗与普通变量几乎相同，但是写操作稍慢，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。

volatile与synchronized区别

1. volatile轻量级，只能修饰变量。synchronized重量级，还可修饰方法
2. volatile只能保证数据的可见性，并不能保证原子性，因为多个线程并发访问volatile修饰的变量不会阻塞；synchronized不仅保证可见性，而且还保证原子性，因为只有获得了锁的线程才能进入临界区，从而保证临界区中的所有语句都全部执行。多个线程争抢synchronized锁对象时，会出现阻塞。
3. 性能方面，synchronized关键字是防止多个线程同时执行一段代码，就会影响程序执行效率，而volatile关键字在某些情况下性能要优于synchronized。

线程安全性包括两个方面，①可见性。②原子性

重排序

数据依赖性

如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。数据依赖分下列三种类型：

名称	代码示例	说明
写后读	a = 1;b = a	写一个变量之后，再读这个位置。
写后写	a = 1;a = 2	写一个变量之后，再写这个变量。
读后写	a = b;b = 1	读一个变量之后，再写这个变量。

只要重排序两个操作的执行顺序，程序的执行结果将会被改变。
前面提到过，编译器和处理器可能会对操作做重排序。编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。
这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作，不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。

as-if-serial语义

指不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器，runtime 和处理器都必须遵守as-if-serial语义。

为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作可能被编译器和处理器重排序。

as-if-serial语义把单线程程序保护了起来，遵守as-if-serial语义的编译器，runtime 和处理器共同为编写单线程程序的程序员创建了一个幻觉：单线程程序是按程序的顺序来执行的。as-if-serial语义使单线程程序员无需担心重排序会干扰他们，也无需担心内存可见性问题。

程序顺序规则

JMM仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前。
在计算机中，软件技术和硬件技术有一个共同的目标：在不改变程序执行结果的前提下，尽可能的开发并行度。编译器和处理器遵从这一目标，从happens- before的定义我们可以看出，JMM同样遵从这一目标。

重排序对多线程的影响

public void writeThread() {
    x = 1;                   //1
    flag = true;           //2
}
Public void readThread() {
    if (flag) {               //3
        int y =  x + 1;     //4
    }
}

假如操作1和操作2做了重排序：程序执行时，线程A首先写标记变量flag，随后线程B读这个变量。由于条件判断为真，线程B将读取变量x。此时，变量x还根本没有被线程A写入，在这里多线程程序的语义被重排序破坏了。

假如操作3和操作4做了重排序：因操作3和操作4存在控制依赖关系，当代码中存在控制依赖性时，会影响指令序列执行的并行度。为此，编译器和处理器会采用猜测（Speculation）执行来克服控制相关性对并行度的影响。以处理器的猜测执行为例，执行线程B的处理器可以提前读取并计算 x + 1，然后把计算结果临时保存到一个名为重排序缓冲（reorder buffer ROB）的硬件缓存中。当接下来操作3的条件判断为真时，就把该计算结果写入变量y中。

在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果（这也是as-if-serial语义允许对存在控制依赖的操作做重排序的原因）；但在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。