JUC并发编程(三)----并发编程基础理论知识

什么是多线程并发编程

并发和并行的概念：

• 并发是指同一个时间段内多个任务同时都在执行，并且都没有执行结束。
• 并行是说在单位时间内多个任务同时在执行。
• 并发任务强调在一个时间段内同时执行，而一个时间段由多个单位时间累积而成，所以说并发的多个任务在单位时间内不一定同时在执行。
• 在单CPU的时代多个任务都是并发执行的，这是因为单个CPU同时只能执行一个任务。在单CPU时代多任务是共享一个CPU的，当一个任务占用CPU运行时，其他任务就会被挂起，当占用CPU的任务时间片用完后，会把CPU让给其他任务来使用，在单CPU时代多线程编程是没有太大意义的，并且线程间频繁的上下文切换还会带来额外开销。
  
  上图为单个CPU上运行两个线程，线程A和线程B是轮流使用CPU进行任务处理的。

上图为双CPU配置，线程A和线程B各自在自己的CPU上执行任务，实现了真正的并行运行。

而在多线程编程中，线程的个数往往多于CPU的个数，所以一般都称多线程并发编程。

为什么要进行多线程并发编程

多核CPU时代的到来打破了单核CPU对多线程效能的限制。多个CPU意味着每个线程可以使用自己的CPU运行，这减少了线程上下文切换的开销，但随着对应用系统性能和吞吐量要求的提高，出现了处理海量数据和请求的要求，这些都对高并发编程有着迫切的需求。

Java中的线程安全问题

谈到线程安全问题，我们先说说什么是共享资源。所谓共享资源，就是说该资源被多个线程所持有或者说多个线程都可以去访问该资源。

线程安全问题是指当多个线程同时读写一个共享资源并且没有任何同步措施时，导致出现脏数据或者其他不可预见的结果的问题。

注意：如果多个线程都只是读取共享资源，而不去修改，那么就不会存在线程安全问题，只有当至少一个线程修改共享资源时才会存在线程安全问题。

解决办法：在线程访问共享变量时进行适当的同步，在Java中最常见的是使用关键字synchronized进行同步。

Java中共享变量的内存可见性问题

首先来看看在多线程下处理共享变量时Java的内存模型，如下图所示:

Java内存模型规定，将所有的变量都存放在主内存中，当线程使用变量时，会把主内存里面的变量复制到自己的工作内存，线程读写变量 时操作的是自己工作内存中的变量。

Java内存模型是一个抽象的概念，实际实现中线程的工作内存如下图所示:

Java内存模型里面的工作内存，就对应这里的L1或者L2缓存或者CPU的寄存器。

当一个线程操作共享变量时，它首先从主内存复制共享变量到自己的工作内存，然后对工作内存里的变量进行处理，处理完后将变量值更新到主内存。

假设线程A和线程B使用不同CPU执行，并且当前两级Cache都为空，那么这时候由于Cache的存在，将会导致内存不可见问题。

• 线程A首先获取共享变量X的值，由于两级Cache都没有命中，这时候加载主内存中X的值，假设X=0。然后把X=0的值缓存到两级缓存，线程A修改X的值为1，然后将其写入两级Cache，并且刷新到主内存。这时候，线程A所在的CPU的两级Cache内和主内存里面的X的值都是1。
• 线程B获取X的值，首先一级缓存没有命中，然后看二级缓存，二级缓存命中了，所以返回X=1；然后线程B修改X的值为2，并将其存放到线程B所在的一级Cache和共享二级Cache，最后更新主内存中的X。到这里一切都是好的。
• 这时候，线程A这次又需要修改X的值，获取时一级缓存命中，并且X=1，到这里问题就出现了，明明线程B已经把X的值修改为了2，为何线程A获取的还是1？这就是共享变量的内存不可见问题，也就是线程B写入的值对线程A不可见。

解决办法：使用Java中的volatile关键字即可。

synchronized关键字

synchronized关键字介绍

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

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

synchronized的内存语义

这个内存语义就可以解决共享变量内存可见性问题。

进入synchronized块的内存语义是把在synchronized块内使用到的变量从线程的工作内存中清除，这样在synchronized块内使用到该变量时就不会从线程的工作内存中获取，而是直接从主内存中获取。

退出synchronized块的内存语义是把在synchronized块内对共享变量的修改刷新到主内存。

其实这也是加锁和释放锁的语义，当获取锁后会清空锁块内本地内存中将会被用到的共享变量，在使用这些共享变量时从主内存进行加载，在释放锁时将本地内存中修改的共享变量刷新到主内存。

除可以解决共享变量内存可见性问题外，synchronized经常被用来实现原子性操作。

注意：synchronized关键字会引起线程上下文切换并带来线程调度开销。

volatile关键字

使用锁的方式可以解决共享变量内存可见性问题，但是使用锁太笨重，因为它会带来线程上下文的切换开销。对于解决内存可见性问题，Java还提供了一种弱形式的同步，也就是使用volatile关键字。

该关键字可以确保一个变量的更新对其他线程马上可见。

volatile的内存语义和synchronized有相似之处，具体来说就是，当线程写入了volatile变量值时就等价于线程退出synchronized同步块（把写入工作内存的变量值同步到主内存），读取volatile变量值时就相当于进入同步块（先清空本地内存变量值，再从主内存获取最新值）。

下面看一个使用volatile关键字解决内存可见性问题的例子。如下代码中的共享变量value是线程不安全的，因为这里没有使用适当的同步措施。

public class ThreadNotSafeInteger{
     
	private int value;
	public int get(){
     
		return value;
	}
	public void set(int value){
     
		this.value = value;
	}
}

synchronized关键字进行同步的方式：

public class ThreadNotSafeInteger{
     
	private int value;
	public synchronized int get(){
     
		return value;
	}
	public synchronized void set(int value){
     
		this.value = value;
	}
}

volatile关键字进行同步

public class ThreadNotSafeInteger{
     
	private volatile int value;
	public int get(){
     
		return value;
	}
	public void set(int value){
     
		this.value = value;
	}
}

使用synchronized和使用volatile是等价的，都解决了共享变量value的内存可见性问题，但是前者是独占锁，同时只能有一个线程调用get()方法，其他调用线程会被阻塞，同时会存在线程上下文切换和线程重新调度的开销。 后者是非阻塞算法，不会造成线程上下文切换的开销。

一般在什么时候才使用volatile关键字？

• 写入变量值不依赖变量的当前值。因为如果依赖当前值，将是获取—计算—写入三步操作，这三步操作不是原子性的，而volatile不保证原子性。
• 读写变量值时没有加锁。因为加锁本身已经保证了内存可见性。

Java中的原子性操作

所谓原子性操作，是指执行一系列操作时，这些操作要么全部执行，要么全部不执行，不存在只执行其中一部分的情况。

在设计计数器时一般都先读取当前值，然后+1,再更新。这个过程是读—改—写的过程，如果不能保证这个过程是原子性的，那么就会出现线程安全问题。 来看下面一段代码：

public class ThreadNotSafeCount{
     
	private Long value;
	public Long getCount(){
     
		return value;
	}
	public void inc(){
     
		++value;
	}
}

上述代码中，线程是不安全的，因为不能保证++value是原子性操作。

保证多个操作的原子性，最简单的办法就是使用synchronized关键字进行同步，修改代码如下:

public class ThreadNotSafeCount{
     
	private Long value;
	public synchronized Long getCount(){
     
		return value;
	}
	public synchronized void inc(){
     
		++value;
	}
}

还有一种更好的实现，那就是内部使用非阻塞CAS算法实现的原子性操作类AtomicLong。

Java中的CAS操作

CAS即Compare and Swap，其是JDK提供的非阻塞原子性操作，它通过硬件保证了比较—更新操作的原子性。

JDK里面的Unsafe类提供了一系列的compareAndSwap方法

• boolean compareAndSwapLong（Object obj, longvalueOffset, long expect, long update）方法：其中compareAndSwap的意思的比较并交换。CAS有四个操作数，分别为：对象内存位置、对象中的变量的偏移量、变量预期值和新的值。其操作含义是，如果对象obj中内存偏移量为valueOffset的变量值为expect，则使用新的值update替换旧的值expect。

关于CAS操作有个经典的ABA问题，具体如下：假如线程I使用CAS修改初始值为A的变量X，那么线程I会首先去获取当前变量X的值（为A），然后使用CAS操作尝试修改X的值为B，如果使用CAS操作成功了，那么程序运行一定是正确的吗？其实未必，这是因为有可能在线程I获取变量X的值A后，在执行CAS前，线程II使用CAS修改了变量X的值为B，然后又使用CAS修改了变量X的值为A。所以虽然线程I执行CAS时X的值是A，但是这个A已经不是线程I获取时的A了。这就是ABA问题。

ABA问题的产生是因为变量的状态值产生了环形转换，就是变量的值可以从A到B，然后再从B到A。如果变量的值只能朝着一个方向转换，比如A到B, B到C，不构成环形，就不会存在问题。JDK中的AtomicStampedReference类给每个变量的状态值都配备了一个时间戳，从而避免了ABA问题的产生。

Unsafe类

Unsafe类中的重要方法

JDK的rt.jar包中的Unsafe类提供了硬件级别的原子性操作，Unsafe类中的方法都是native方法，它们使用JNI的方式访问本地C++实现库。 其主要方法如下：

• long objectFieldOffset(Field field) 方法：返回指定的变量再所属类中的内存偏移地址，该偏移地址仅仅再该Unsafe函数中访问指定字段时使用。 如下代码使用Unsafe类获取变量value在AtomicLong对象中的内存偏移

static{
     
	try{
     
		valueOffset = unsafe.objectFieldOffset(
	AtomicLong.class.getDeclaredField("value"));
	}catch(Exception e){
     
		throw new Error(e)
	}
}

• int arrayBaseOffset(Class arrayClass)方法：获取数组中第一个元素的地址。
• int arrayIndexScale(Class arrayClass)方法：获取数组中一个元素占用的字节。
• boolean compareAndSwapLong（Object obj, long offset, long expect, long update）方法：比较对象obj中偏移量为offset的变量的值是否与expect相等，相等则使用update值更新，然后返回true，否则返回false。
• public native long getLongvolatile（Object obj, long offset）方法：获取对象obj中偏移量为offset的变量对应volatile语义的值。
• void putLongvolatile（Object obj, long offset, longvalue）方法：设置obj对象中offset偏移的类型为long的field的值为value，支持volatile语义。
• void putOrderedLong（Object obj, long offset, long value）方法：设置obj对象中offset偏移地址对应的long型field的值为value。这是一个有延迟的putLongvolatile方法，并且不保证值修改对其他线程立刻可见。只有在变量使用volatile修饰并且预计会被意外修改时才使用该方法。
• void park（boolean isAbsolute, long time）方法：阻塞当前线程，其中参数isAbsolute等于false且time等于0表示一直阻塞。time大于0表示等待指定的time后阻塞线程会被唤醒，这个time是个相对值，是个增量值，也就是相对当前时间累加time后当前线程就会被唤醒。如果isAbsolute等于true，并且time大于0，则表示阻塞的线程到指定的时间点后会被唤醒，这里time是个绝对时间，是将某个时间点换算为ms后的值。另外，当其他线程调用了当前阻塞线程的interrupt方法而中断了当前线程时，当前线程也会返回，而当其他线程调用了unPark方法并且把当前线程作为参数时当前线程也会返回。
• void unpark（Object thread）方法：唤醒调用park后阻塞的线程。
• long getAndSetLong（Object obj, long offset, long update）方法：获取对象obj中偏移量为offset的变量volatile语义的当前值，并设置变量volatile语义的值为update。 其源码如下：

@HotSpotIntrinsicCandidate
    public final long getAndSetLong(Object o, long offset, long newValue) {
     
        long v;
        do {
     
            v = getLongVolatile(o, offset);
        } while (!weakCompareAndSetLong(o, offset, v, newValue));
        return v;
    }

首先通过getLongvolatile获取当前变量的值，然后使用CAS原子操作设置新值。这里使用while循环是考虑到，在多个线程同时调用的情况下CAS失败时需要重试。

• long getAndAddLong（Object obj, long offset, long addValue）方法：获取对象obj中偏移量为offset的变量volatile语义的当前值，并设置变量值为原始值+addValue。其源码如下：

@HotSpotIntrinsicCandidate
    public final long getAndAddLong(Object o, long offset, long delta) {
     
        long v;
        do {
     
            v = getLongVolatile(o, offset);
        } while (!weakCompareAndSetLong(o, offset, v, v + delta));
        return v;
    }

类似getAndSetLong的实现，只是这里进行CAS操作时使用了原始值+传递的增量参数addValue的值。

使用Unsafe类

代码演练:

public class TestUnSafe {
     

    //获取Unsafe的实例（1）
    static  final Unsafe unsafe = Unsafe.getUnsafe();

    //记录变量state在类TestUnSafe中的偏移量（2）
    static long stateOffset = 0;

    //变量(3)
    private  volatile  long state = 0;

    static {
     
        try {
     
            //获取state变量在类TestUnSafe中的偏移量(4)
            stateOffset = unsafe.objectFieldOffset(TestUnSafe.class.getDeclaredField("state"));
        }catch ( Exception e){
     
            System.out.println(e.getLocalizedMessage());
            throw  new Error(e);
        }
    }

    public static void main(String[] args) {
     
        //创建实例，并且设置state值为1（5）
        TestUnSafe test = new TestUnSafe();
        //（6）
        Boolean success = unsafe.compareAndSwapInt(test,stateOffset,0,1);
        System.out.println(success);
    }
}

在如上代码中，代码（1）获取了Unsafe的一个实例，代码（3）创建了一个变量state并初始化为0。

代码（4）使用unsafe.objectFieldOffset获取TestUnSafe类里面的state变量，在TestUnSafe对象里面的内存偏移量地址并将其保存到stateOffset变量中。

代码（6）调用创建的unsafe实例的compareAndSwapInt方法，设置test对象的state变量的值。具体意思是，如果test对象中内存偏移量为stateOffset的state变量的值为0，则更新该值为1。

运行上面的代码，我们期望输出true，然而执行后会输出如下结果。

为找出原因，必然要查看getUnsafe的代码。

 @CallerSensitive
    public static Unsafe getUnsafe() {
     
    	//(7)
        Class<?> caller = Reflection.getCallerClass();
        //(8)
        if (!VM.isSystemDomainLoader(caller.getClassLoader()))
            throw new SecurityException("Unsafe");
        return theUnsafe;
    }
	
	//判断loader是不是BootStrap类加载器(9)
	public static boolean isSystemDomainLoader(ClassLoader loader) {
     
        return loader == null;
    }

代码（7）获取调用getUnsafe这个方法的对象的Class对象，这里是TestUnSafe. class。

代码（8）判断是不是Bootstrap类加载器加载的localClass，在这里是看是不是Bootstrap加载器加载了TestUnSafe.class。很明显由于TestUnSafe.class是使用AppClassLoader加载的，所以这里直接抛出了异常。

思考一下，这里为何要有这个判断？我们知道Unsafe类是rt.jar包提供的，rt.jar包里面的类是使用Bootstrap类加载器加载的，而我们的启动main函数所在的类是使用AppClassLoader加载的，所以在main函数里面加载Unsafe类时，根据委托机制，会委托给Bootstrap去加载Unsafe类。

如果没有代码（2.2.8）的限制，那么我们的应用程序就可以随意使用Unsafe做事情了，而Unsafe类可以直接操作内存，这是不安全的，所以JDK开发组特意做了这个限制，不让开发人员在正规渠道使用Unsafe类，而是在rt.jar包里面的核心类中使用Unsafe功能。

我们可以使用万能的反射来获取Unsafe实例方法

public class TestUnSafe {
     

    //获取Unsafe的实例（1）
    static  final Unsafe unsafe;

    //记录变量state在类TestUnSafe中的偏移量（2）
    static long stateOffset = 0;

    //变量(3)
    private  volatile  long state = 0;

    static {
     
        try {
     
            //使用反射获取Unsafe的成员变量theUnsafe
            Field field = Unsafe.class.getDeclaredField("theUnsafe");
            //设置为可存取
            field.setAccessible(true);
            //获取该变量的值
            unsafe = (Unsafe) field.get(null);

            //获取state变量在类TestUnSafe中的偏移量(4)
            stateOffset = unsafe.objectFieldOffset(TestUnSafe.class.getDeclaredField("state"));
        }catch ( Exception e){
     
            System.out.println(e.getLocalizedMessage());
            throw  new Error(e);
        }
    }

    public static void main(String[] args) {
     
        //创建实例，并且设置state值为1（5）
        TestUnSafe test = new TestUnSafe();
        //（6）
        Boolean success = unsafe.compareAndSwapInt(test,stateOffset,0,1);
        System.out.println(success);
    }
}

通过反射获取unsafe的实例，运行后输出结果如下：

Java指令重排序

Java内存模型允许编译器和处理器对指令重排序以提高运行性能，并且只会对不存在数据依赖性的指令重排序。在单线程下重排序可以保证最终执行的结果与程序顺序执行的结果一致，但是在多线程下就会存在问题。

下面看一个例子：

int a = 1;//(1)
int b = 2;//(2)
int c = a+b;//(3)

在上述代码中，变量c的值依赖a和b的值，所以重排序后能够保证(3)的操作在(2)（1）之后，但是(1)（2）谁先执行就不一定了，这在单线程下不会存在问题，因为并不影响最终结果。

下面看一个多线程的例子：

public class SortThreadTest {
     
    private  static  int num = 0;
    private  static  boolean ready = false;


    public  static  class  ReadThread extends  Thread{
     
        @Override
        public void run() {
     
            while (!Thread.currentThread().isInterrupted()){
     
                if(ready){
      //(1)
                    System.out.println(num+num);
                }
                System.out.println("read thread。。。");//(2)
            }
        }
    }

    public  static  class  Writethread extends  Thread{
     
        @Override
        public void run() {
     
            num = 2;//(3)
            ready = true; //(4)
            System.out.println("writeThread set over...");
        }
    }

    public static void main(String[] args) throws InterruptedException {
     
        ReadThread rt = new ReadThread();
        rt.start();
        Writethread wt = new Writethread();
        wt.start();
        Thread.sleep(10);
        rt.interrupt();
        System.out.println("main exit");
    }
}

先来看看指令重排序会造成什么影响，由于代码(1)、（2）、（3）、（4）之间不存在依赖关系，所以写线程的代码(3)(4)可能被重排序为先执行(4)再执行(3)，那么执行(4)后，读线程可能已经执行了(1)操作，并且在(3)执行前开始执行(2)操作，这时候输出结果为0，而不是4.

重排序在多线程下会导致非预期的程序执行结果，而使用volatile修饰ready就可以避免重排序和内存可见性问题。

写volatile变量时，可以确保volatile写之前的操作不会被编译器重排序到volatile写之后。读volatile变量时，可以确保volatile读之后的操作不会被编译器重排序到volatile读之前。

伪共享

什么是伪共享

为了解决计算机系统中主内存与CPU之间运行速度差问题，会在CPU与主内存之间添加一级或者多级高速缓冲存储器(Cache)。这个Cache一般是被集成到CPU内部的，所以也叫CPU Cache。如下图所示：

在Cache内部是按行存储的，其中每一行称为一个Cache行。Cache行是Cache与主内存进行数据交换的单位，Cache行的大小一般为2的幂次数字节。

当CPU访问某个变量时，首先会取看CPU Cache内是否有该变量，如果有则直接从中获取，否则就去主内存里面获取该变量，然后把该变量所在内存区域的一个Cache行大小的内存复制到Cache中。由于存放到Cache行的是内存块而不是单个变量，所以可能会把多个变量存放到一个Cache行中。当多个线程同时修改一个缓存行里面的多个变量时，由于同时只能有一个线程操作缓存行，所以相比将每个变量放到一个缓存行，性能会有所下降，这就是伪共享。

在该图中，变量x和y同时被放到了CPU的一级和二级缓存，当线程1使用CPU1对变量x进行更新时，首先会修改CPU1的一级缓存变量x所在的缓存行，这时候在缓存一致性协议下，CPU2中变量x对应的缓存行失效。那么线程2在写入变量x时就只能去二级缓存里查找，这就破坏了一级缓存。而一级缓存比二级缓存更快，这也说明了多个线程不可能同时去修改自己所使用的CPU中相同缓存行里面的变量。更坏的情况是，如果CPU只有一级缓存，则会导致频繁地访问主内存。

为何会出现伪共享

伪共享的产生是因为多个变量被放入了一个缓存行中，并且多个线程同时去写入缓存行中不同的变量。那么为何多个变量会被放入一个缓存行呢？其实是因为缓存与内存交换数据的单位就是缓存行，当CPU要访问的变量没有在缓存中找到时，根据程序运行的局部性原理，会把该变量所在内存中大小为缓存行的内存放入缓存行。

long a;
long b;
long c;
long d;

如上代码声明了四个long变量，假设缓存行的大小为32字节，那么当CPU访问变量a时，发现该变量没有在缓存中，就会去主内存把变量a以及内存地址附近的b、c、d放缓存行。也就是地址连续的多个变量才有可能会被放到一个缓存行中。

当创建数组时，数组里面的多个元素就会被放入同一个缓存行。那么在单线程下多个变量被放入同一个缓存行对性能有影响吗？其实在正常情况下单线程访问时将数组元素放入一个或者多个缓存行对代码执行是有利的，因为数据都在缓存中，代码执行会更快。举例说明：

代码1：

public class TestForContent {
     
    static  final int LINE_NUM = 1024;
    static  final int COLUM_NUM = 1024;

    public static void main(String[] args) {
     
        long[][] array = new long[LINE_NUM][COLUM_NUM];

        long startTime = System.currentTimeMillis();
        for (int i = 0; i < LINE_NUM; i++) {
     
            for (int j = 0; j < COLUM_NUM; j++) {
     
                array[i][j] = i*2+j;
            }
        }

        long endTime = System.currentTimeMillis();
        long cacheTime = endTime -startTime;
        System.out.println("cache time："+cacheTime);
    }
}

执行结果:

代码2：

public class TestForContent1 {
     
    static  final int LINE_NUM = 1024;
    static  final int COLUM_NUM = 1024;

    public static void main(String[] args) {
     
        long[][] array = new long[LINE_NUM][COLUM_NUM];

        long startTime = System.currentTimeMillis();
        for (int i = 0; i < LINE_NUM; i++) {
     
            for (int j = 0; j < COLUM_NUM; j++) {
     
                array[j][i] = i*2+j;
            }
        }

        long endTime = System.currentTimeMillis();
        long cacheTime = endTime -startTime;
        System.out.println("cache time："+cacheTime);
    }
}

执行结果:

代码1明显比代码2执行得快，这时因为数组内数组元素的内部地址是连续的，当访问数组第一个元素时，会把第一个元素后的若干元素一块放入缓存行，这样顺序访问数组元素时会在缓存中直接命中，因而就不会去主内存读取了，后续访问也是这样。也就是说，当顺序访问数组里面元素时，如果当前元素在缓存没有命中，那么会从主内存一下子读取后续若干个元素到缓存。

而代码2是跳跃式访问数组元素。不是顺序的，这破坏了程序访问的局部性原则，并且缓存是有容量控制的，当缓存满了时会根据一定淘汰算法替换缓存行，这会导致从内存置换过来的缓存行的元素还没等到被读取就被替换掉了。

所以在单个线程下顺序修改一个缓存行中的多个变量，会充分利用程序运行的局部性原则，从而加速了程序的运行。而在多线程下并发修改一个缓存行中的多个变量时就会竞争缓存行，从而降低程序运行性能。

如何避免伪共享

在JDK8之前一般都是通过字节填充的方式来避免该问题，也就是创建一个变量时使用填充字段填充该变量所在的缓存行，这样就避免了将多个变量存放在同一个缓存行中，例如如下代码：

public final static class FilledLong{
     
	public volatile long value = 0L;
	public long p1,p2,p3,p4,p5,p6;
}

假如缓存行为64字节，那么我们在FilledLong类里面填充了6个long类型的变量，每个long类型变量占用8字节，加上value变量的8字节总共56字节。另外，这里FilledLong是一个类对象，而类对象的字节码的对象头占用8字节，所以一个FilledLong对象实际会占用64字节的内存，这正好可以放入一个缓存行。

JDK8提供了一个sun.misc.Contended注解，用来解决伪共享问题：

@sun.misc.Contended
public final static class FilledLong{
     
	public volatile long value = 0L;
}

在这里注解用来修饰类，当然也可以修饰变量。

需要注意的是，在默认情况下，@Contended注解只用于Java核心类，比如rt包下的类。如果用户类路径下的类需要使用这个注解，则需要添加JVM参数：-XX:-RestrictContended。填充的宽度默认为128，要自定义宽度则可以设置-XX:ContendedPaddingWidth参数。

锁的概述

乐观锁与悲观锁

悲观锁指对数据被外界修改持保守态度，认为数据很容易就会被其他线程修改，所以在数据被处理前先对数据进行加锁，并在整个数据处理过程中，使数据处于锁定状态。悲观锁的实现往往依靠数据库提供的锁机制，即在数据库中，在对数据记录操作前给记录加排它锁。如果获取锁失败，则说明数据正在被其他线程修改，当前线程则等待或者抛出异常。如果获取锁成功，则对记录进行操作，然后提交事务后释放排它锁。

乐观锁是相对悲观锁来说的，它认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁，而是在进行数据提交更新时，才会正式对数据冲突与否进行检测。

乐观锁并不会使用数据库提供的锁机制，一般在表中添加version字段或者使用业务状态来实现。乐观锁直到提交时才锁定，所以不会产生任何死锁。

公平锁与非公平锁

根据线程获取锁的抢占机制，锁可以分为公平锁和非公平锁，公平锁表示线程获取锁的顺序是按照线程请求锁的时间早晚来决定的，也就是最早请求锁的线程将最早获取到锁。而非公平锁则在运行时闯入，也就是先来不一定先得。

ReentrantLock提供了公平和非公平锁的实现

• 公平锁：ReentrantLock pairLock = newReentrantLock（true）。
• 非公平锁：ReentrantLock pairLock = newReentrantLock（false）。如果构造函数不传递参数，则默认是非公平锁。

例如，假设线程A已经持有了锁，这时候线程B请求该锁其将会被挂起。当线程A释放锁后，假如当前有线程C也需要获取该锁，如果采用非公平锁方式，则根据线程调度策略，线程B和线程C两者之一可能获取锁，这时候不需要任何其他干涉，而如果使用公平锁则需要把C挂起，让B获取当前锁。

在没有公平性需求的前提下尽量使用非公平锁，因为公平锁会带来性能开销。

独占锁与共享锁

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

独占锁保证任何时候都只有一个线程能得到锁，ReentrantLock就是以独占方式实现的。共享锁则可以同时由多个线程持有，例如ReadWriteLock读写锁，它允许一个资源可以被多线程同时进行读操作。

独占锁是一种悲观锁，由于每次访问资源都先加上互斥锁，这限制了并发性，因为读操作并不会影响数据的一致性，而独占锁只允许在同一时间由一个线程读取数据，其他线程必须等待当前线程释放锁才能进行读取。

共享锁则是一种乐观锁，它放宽了加锁的条件，允许多个线程同时进行读操作。

可重入锁

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

下面来看一个例子：

public class Hello {
     
    public  synchronized  static void helloA(){
     
        System.out.println("hello A");
    }

    public  synchronized static void helloB(){
     
        System.out.println("hello B");
        helloA();
    }
   
}

在如上代码中，调用helloB方法前会先获取内置锁，然后打印输出。之后调用helloA方法，在调用前会先去获取内置锁，如果内置锁不是可重入的，那么调用线程将会一直被阻塞。

实际上，synchronized内部锁是可重入锁。可重入锁的原理是在锁内部维护一个线程标示，用来标示该锁目前被哪个线程占用，然后关联一个计数器。一开始计数器值为0，说明该锁没有被任何线程占用。当一个线程获取了该锁时，计数器的值会变成1，这时其他线程再来获取该锁时会发现锁的所有者不是自己而被阻塞挂起。

但是当获取了该锁的线程再次获取锁时发现锁拥有者是自己，就会把计数器值加+1，当释放锁后计数器值-1。当计数器值为0时，锁里面的线程标示被重置为null，这时候被阻塞的线程会被唤醒来竞争获取该锁。

自旋锁

由于Java中的线程是与操作系统中的线程一一对应的，所以当一个线程在获取锁（比如独占锁）失败后，会被切换到内核状态而被挂起。当该线程获取到锁时又需要将其切换到内核状态而唤醒该线程。而从用户状态切换到内核状态的开销是比较大的，在一定程度上会影响并发性能。

自旋锁则是，当前线程在获取锁时，如果发现锁已经被其他线程占有，它不马上阻塞自己，在不放弃CPU使用权的情况下，多次尝试获取（默认次数是10，可以使用-XX:PreBlockSpinsh参数设置该值），很有可能在后面几次尝试中其他线程已经释放了锁。如果尝试指定的次数后仍没有获取到锁则当前线程才会被阻塞挂起。由此看来自旋锁是使用CPU时间换取线程阻塞与调度的开销，但是很有可能这些CPU时间白白浪费了。