synchronized

synchronized块是Java 提供的一种原子性内置锁， Java 中的每个对象都可以把它当作一个同步锁来使用，这些Java 内置的使用者看不到的锁被称为内部锁，也叫作监视器锁。synchronized 关键字底层原理属于 JVM 层面。线程的执行代码在进入synchronized 代码块前会自动获取内部锁，这时候其他线程访问该同步代码块时会被阻塞挂起。拿到内部锁的线程会在正常退出同步代码块或者抛出异常后或者在同步块内调用了该内置锁资源的wait 系列方法时释放该内置锁。内置锁是排它锁，也就是当一个线程获取这个锁后，其他线程必须等待该线程释放锁后才能获取该锁。

由于Java 中的线程是与操作系统的原生线程一一对应的，所以当阻塞一个线程时，需要从用户态切换到内核态执行阻塞操作，这是很耗时的操作，而synchronized的使用就会导致上下文切换。

庆幸的是，JDK1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销，所以现在的 synchronized 锁效率也很不错了。

synchronized 同时具有内存语义，这个内存语义可以解决共享变量内存可见性问题。进入synchronized 块的内存语义是把在synchronized 块内使用到的变量从线程的工作内存中清除，这样在synchronized 块内使用到该变量时就不会从线程的工作内存中获取，而是直接从主内存中获取。退出synchronized 块的内存语义是把在synchronized 块内对共享变量的修改刷新到主内存。

volatile

使用锁的方式可以解决共享变量内存可见性问题，但是使用锁太笨重，因为它会带来线程上下文的切换开销。对于解决内存可见性问题， Java 还提供了一种弱形式的同步，也就是使用volatile 关键字。该关键字可以确保对一个变量的更新对其他线程马上可见。当一个变量被声明为volatile 时，线程在写入变量时不会把值缓存在寄存器或者其他地方，而是会把值刷新回主内存。当其他线程读取该共享变量时，会从主内存重新获取最新值，而不是使用当前线程的工作内存中的值。volatile 的内存语义和synchronized 的内存语义有相似之处，具体来说就是，当线程写入了volatile 变量值时就等价于线程退出synchronized 同步块（把写入工作内存的变量值同步到主内存），读取volatile 变量值时就相当于进入同步块（先清空本地内存变量值，再从主内存获取最新值）。

volatile 只能保证共享变量的可见性，不能解决读—改一写等的原子性问题。下例中，cnt变量已经使用volatile 修饰，最终结果却不正确。

@Unsafe
public class IntegerCount {
    static volatile int cnt=0;
    public static void main(String[] args) throws InterruptedException {
//线程不安全
        Thread[] threads=new Thread[10];
        for (int i=0;i<threads.length;i++){
            threads[i]=new Thread(()->{
                for (int j=0;j<10000;j++){
                    cnt++;
                }
            });
            threads[i].start();
        }
        for (Thread thread : threads) {
            thread.join();
        }

        System.out.println("cnt:"+cnt);
    }

}

一般来说，volatile适合状态验证，不适合累加值，在修饰状态标记量时，要保证对：

变量的写操作不依赖于当前值
该变量没有包含在具有其他变量的式子中

//volatile经典用法
volatile boolean asleep
...
	while(!asleep){
		//do some work
	}

CAS

在Java 中，锁在并发处理中占据了一席之地，但是使用锁有一个不好的地方，就是当一个线程没有获取到锁时会被阻塞挂起，这会导致线程上下文的切换和重新调度开销。Java 提供了非阻塞的volatile 关键字来解决共享变量的可见性问题，这在一定程度上弥补了锁带来的开销问题，但是volatile 只能保证共享变量的可见性，不能解决读—改一写等的原子性问题。CAS 即Compare and Swap ，其是JDK 提供的非阻塞原子性操作，它通过硬件保证了比较更新操作的原子性。JDK 里面的Unsafe 类提供了一系列的compareAndSwap*方法，例如:

boolean compareAndSwapLong(Object obj ,long valueOffset,long expect, long update）方
法：其中compareAndSwap 的意思是比较并交换。CAS 有四个操作数，分别为：对象内存位置、对象中的变量的偏移量、变量预期值和新的值。其操作含义是，如果对象obj 中内存偏移量为valueOffset 的变量值为expect ，则使用新的值update 替换旧的值expect 。这是处理器提供的一个原子性指令。

Unsafe

JDK 的rt.jar包中的Unsafe 类提供了硬件级别的原子性操作， Unsafe 类中的方法都是native 方法，它们使用JNI的方式访问本地C++实现，除了上文提到的compareAndSwap*方法，其中还有几个重要的方法：

long objectFieldOffset(Field field） 方法：返回指定的变量在所属类中的内存偏移地址，该偏移地址仅仅在该Unsafe 函数中访问指定宇段时使用。
void park(boolean isAbsolute, long time） 方法：阻塞当前线程
void unpark(Object thread） 方法：唤醒调用park后阻塞的线程。

锁

乐观锁和悲观锁

悲观锁指对数据被外界修改持保守态度，认为数据很容易就会被其他线程修改，所以在数据被处理前先对数据进行加锁，并在整个数据处理过程中，使数据处于锁定状态。悲观锁的实现往往依靠数据库提供的锁机制，即在数据库中，在对数据记录操作前给记录加排它锁。如果获取锁失败，则说明数据正在被其他线程修改，当前线程则等待或者抛出异常。如果获取锁成功，则对记录进行操作，然后提交事务后释放排它锁。
乐观锁是相对悲观锁来说的，它认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁，而是在进行数据提交更新时，才会正式对数据冲突与否进行检测。

公平锁和非公平锁

根据线程获取锁的抢占机制，锁可以分为公平锁和非公平锁：

公平锁表示线程获取锁的顺序是按照线程请求锁的时间早晚来决定的，也就是最早请求锁的线程将最早获取到锁。
非公平锁可以在运行时闯入，也就是先来不一定先得。

独占锁和共享锁

根据锁只能被单个线程持有还是能被多个线程共同持有，锁可以分为独占锁和共享锁：

独占锁保证任何时候都只有一个线程能得到锁， ReentrantLock 就是以独占方式实现的。独占锁是一种悲观锁，由于每次访问资源都先加上互斥锁，这限制了并发性，因为读操作并不会影响数据的一致性，而独占锁只允许在同一时间由一个线程读取数据，其他线程必须等待当前线程释放锁才能进行读取。
共享锁则可以同时由多个线程持有，例如ReadWriteLock 读写锁，它允许一个资源可以被多线程同时进行读操作。共享锁则是一种乐观锁，它放宽了加锁的条件，允许多个线程同时进行读操作

可重入锁

当一个线程要获取一个被其他线程持有的独占锁时，该线程会被阻塞，那么当一个线程再次获取它自己己经获取的锁时，如果不被阻塞，那么我们说该锁是可重入的，也就是只要该线程获取了该锁，那么可以无限次数（严格来说是有限次数）地进入被该锁锁住的代码。

自旋锁

由于Java 中的线程是与操作系统中的线程一一对应的，所以当一个线程在获取锁（比如独占锁）失败后，会被切换到内核状态而被挂起。当该线程获取到锁时又需要将其切换到内核状态而唤醒该线程。而从用户状态切换到内核状态的开销是比较大的，在一定程度上会影响并发性能。自旋锁则是，当前线程在获取锁时，如果发现锁已经被其他线程占有，它不马上阻塞自己，在不放弃CPU 使用权的情况下，多次尝试获取，很有可能在后面几次尝试中其他线程己经释放了锁。如果尝试指定的次数后仍没有获取到锁则当前线程才会被阻塞挂起。由此看来自旋锁是使用CPU 时间换取线程阻塞与调度的开销，但是很有可能这些CPU 时间白白浪费了。

冰冻橘子的自留地

java多线程编程基础（二）