Java并发（一）：线程基本点详解

目录

• JVM内存模型
     1）原子性
     2）可见性
     3）有序性
• voliate
• 线程
• Java线程
• Synchronized的作用与原理
• ReentrantLock
• ThreadLocal

Java内存模型（Java Memory Model，JMM）
       Java内存模型本身只是一种抽象的概念，它声明了一系列规则或规范（主要是声明了主内存与工作内存交互的一些细节），来解决Java在硬件层面上内存访问的差异，也是Java得以跨平台的原因之一。
　　从内存模型的角度出发，Java中内存可分为主内存和线程工作内存两种，所有变量都存储在主内存中，而线程工作内存主要存储线程私有数据。 主内存是共享内存区域，所有线程都可以访问，但线程并不能直操作主内存中的变量，线程如果想操作主内中的变量，需要先将变量从主内存中拷贝到自己的工作内存中，操作完成后再将变量刷回主内存，只有当数据刷回主内存后，最新的结果对其它线程才是可见的（对于volitile变量同样如此），也就说线程之间的通信（这里指可见性）都必须通过主内存来完成。比如下图

　　注：这里的主内存与工作内存与堆、栈并不是同一层次上的划分，出发角度不一样，前者是为了解决内存访问差异而划分的，后者代表程序运行时内存的划分。但从变量存储的区域上来看，主内存可对应理解成堆，存储对象但不包括存储局部变量及方法参数，而工作内存则可以对应理解成栈，存储线程局部变量及方法参数等。

Java内存模型的特征
　　可见性：可见性是指当线程修改共享变量时，其它线程何时可以看到修改后的信息。上面已经说过，只有当数据刷回主内存之后，对其它线程才是可见的。所以这种可见性不一定是及时的，线程A对共享变量的修改会先反映在自己的工作内存中，然后再写回主内存中，如果在修改完但还没有回写的情况下，线程B去获取此时得到的仍然是旧值。针对这种情况，Java提供了volatile关键字，来保证并发修改下变量的可见性，关于volatile稍后说明。

　　原子性：表示对共享数据某个操作的原子性，由于整个操作的原子性，所以在保证原子性的同时也保证了可见性。java中可以简单的通过synchronized、lock等来达到，synchronized也稍后说明。

　　有序性：出于优化的考虑，JVM有可能会对指令进行重排序，所以指令的执行顺序并不一定等于代码的编写顺序，但JVM保证最终逻辑上的有序性。比如int a = 3; int b = 4; int c = a + b;  执行时JVM并不保证a一定比b先定义，但从逻辑上会保证，c一定在a,b定义之后才会执行。对于被volatile修饰的变量，jvm不会对其进行重排序。

voliate关键字的作用
　　对volatile变量的操作同样也遵从内存间的交互规范，与普通变量的区别在于：

• 对volatile变量的修改会保证及时(同时)反映到线程工作内存和主内存中，而且在每次使用volatile变量前线程都会先从主内存中获取最新值。这点就保证了对volatile变量修改的及时可见。
• 除可见性外，对于volatile变量jvm不会进行指令重排，指令的执行顺序和程序中的顺序严格一致，如volatile int a =3; int b = 4;JVM会保证a在b之前定义。再比如在JDK1.5之前双重check的懒汉式单例也需要用到volatile来确保对象可以正常使用，原因是，对象创建一般会经历内存分配—>初始化—>返回对象引用等一系列操作。但由于对象引用在内存分配之后就已经确定了，与对象是否初始化并没有逻辑上的关系，所以如果指令重排的话，对象就有可能在尚未初始化完成就提前返回了，即内存分配—>返回对象引用—>初始化，使用的时候，就有可能出现问题。
• volatile虽然保证对变量修改的及时可见，但并不能保证操作的原子性。

/** 并发情况下，及时获取对该值的修改 */  
  volatile boolean isStop = false;

	public void execute(){
		while(isStop){
			...
		}
	}
	
	public void toStop(){
		isStop = true;
	}

线程简介
　　线程可以分为内核线程(KLT)和用户线程(UT)两种，内核线程由操作系统分配，程序一般不直接调用，而是通过调用系统为内核线程提供的接口—轻量级进程（LWP），去调用内核线程，轻量级进程与内核线程是一对一的关系，每个轻量级进程都是一个独立的调度单元。Java线程模型就是基于操作系统原生线程模型来实现的，在window和unix下，可以理解为下图：

　　用户线程建立在用户空间的线程库上，创建、销毁、同步、调度等操作都在用户态中完成，不需要内核参与，因此它的操作相对来更快速而且消耗更低，但难点在于由于没有内核线程的支持，需要手动切换、调度等操作，实现起来非常复杂，目前基于纯用户线程的设计已经很少用了，某些情况下两者会配合使用。　　

Java线程简介
线程状态：java线程主要有5种状态new、runnable、blocked、wait/timed_waiting(有限wait)、terminated(执行完毕)，通过getState()可获取当前状态。
优先级：优先级从1-10（默认5），新线程优先级默认继承于父线程。 这里的优先级只是Java中的划分，并不对应底层系统的优先级。

守护线程：守护线程在后台运行，当程序中全是守护线程时，jvm会自动退出。在守护线程中应该永远不要去访问如文件、数据库资源这些操作，因为守护线程很可能在任何地方被中断。

sleep(millis)：让当前线程休眠一段时间，休眠时间是由参数设定，线程状态由runnable转为timed_waiting，休眠期间释放cpu资源但不释放监视器。在时间到达或线程被中断前，该线程都不会再被调起。在waiting期间如果该线程被任何其它线程中断，则该方法抛出异常，并且清除中断标记。

wait()/wait(millis)、notify()/notifyAll()：线程状态由runnable转为waiting/timed_waiting，与sleep()的区别在于它等待时间到达或其它线程notify，且在waiting期间释放cpu资源释放锁，同样受线程中断影响。这两组方法位于根类Object中，两者配合实现一种等待—唤醒的线程协作方式，常用于生产—消费者模式下。

join()/join(millis)：等待被调用线程中止，当前线程状态由runnable转为waiting/timed_waiting，所以waiting过程中同样受中断影响。如下：f2等待f1执行完成，main线程又等待f2执行完成。

public static void main(String[] args) throws InterruptedException {
		Thread f1 = new Thread(()->{
			try {
				Thread.sleep(10000);
				System.out.println(Thread.currentThread().getName());
			} catch (InterruptedException e) {}
		});
		
		
		Thread f2 = new Thread(()->{
			try {
				f1.join();
				System.out.println("f1[end], f2[start]");
			} catch (InterruptedException e) {}
		});
		
		f1.start();
		f2.start();
		
		f2.join();
		System.out.println("over");
	}

 yield()：使正在运行的线程释放cpu资源重新回到可执行状态，线程状态由runnable（正在执行）到 runnable（可执行），所以线程有可能马上又被执行，由于不会进入wait状态，所以yield()方法并不受线程中断的影响。此外yield()方法只能使同优先级或者高优先级的线程得到运行的机会。

interrupt()：中断线程，本身只是设置线程的中断标记而已，但中断会使处于waiting期间的线程抛出一个中断异常InterruptedException，原因是由于线程处于waiting期间，无法被调起执行，不能自己检测中断，所以JVM会通过抛出异常的方式来唤醒线程。通过中断/处理中断异常/检测中断状态也是一种比较常见的线程间通信的协作方式。

stop():终止线程会释放它已经锁定的所有监视器，很容易造成的问题就是数据不一致性。这就相当于一个DB事务中途退出，对于DB而言事务中途退出会导致事务全部回滚，这没什么问题，但在Java程序中，原子性操作的中途退出并没有回滚一说，而是会产生并发问题，所以数据不一致性的问题就很可能产生。即使要终止线程也可以通过上方说的中断方式，来安全退出。

线程挂起suspend()与恢复resume()：这两个方法在Java中被标记为过时的不再使用的方法，原因是因为通过suspend()挂起的线程，不会释放锁，直到在其它线程中调用resume()恢复，且继续运行完成才会释放锁。因此有可能造成两种情况：一就是如果调用resume()的线程也需要获取相同锁，由于原线程并未释放，那么就会造成死锁。二如果resume()在suspend()之前被执行，则原线程永远也无法被恢复。与wait()/notify()的区别在于情况一，wait会释放锁所以不会造成死锁情况，情况二的话wait也不可避免。

	public void testDeadlock() throws InterruptedException{
		final Object lock = new Object();
		Thread t = new Thread(()->{
			synchronized (lock) {	//lock
				try {
					Thread.sleep(1000);
				} catch (InterruptedException e) {}
				System.out.println("----t.running");
			}
		});
		
		Thread suspend = new Thread(()->{
			t.suspend();
			System.out.println("----t.suspend");
		});
		
		
		Thread resume = new Thread(()->{
			synchronized (lock) {
				t.resume();
				System.out.println("----t.resume");
			}
		});
		
		t.start();
		Thread.sleep(100);
		suspend.start();		//suspend
		Thread.sleep(100);
		resume.start();			//resume
		
		t.join();
		suspend.join();
		resume.join();
		
		System.out.println("----over");
	}

线程异常处理：除了对线程内部的代码进行try...catch外，也可以设置异常处理程序

@Test
	public void testUncaughtExceptionHandler() throws InterruptedException{
		Thread th = new Thread(()->{
			int i = 1/0;
		});
		th.setUncaughtExceptionHandler(new UncaughtExceptionHandler() {
			@Override
			public void uncaughtException(Thread t, Throwable e) {
				System.out.println("由于没有捕获异常,所以执行自定义的处理方式" + e.getMessage());
			}
		});
		th.start();
	}

Synchronized块的作用与原理
　　synchronized块可以保证操作的原子性和可见性，synchronized底层通过监视器（或内置锁）实现，监视器在jvm中的模型可分为：入口区、持有者、等待区三部分。

 

　　synchronized块的进入和退出分别对应指令monitorenter、monitorexit，且synchronized同步块对同一线程是可重入的，重入通过为内置锁关联一个计数器和持有者线程来实现，计数器为0时即表示监视器未被任何占用。当某线程请求获取到一个未被占用的锁时，JVM将记录锁的持有者，并计数+1，如果同一线程再次请求获取这个锁，计数器依次+１；持有线程每退出一个监视块时，计数器－1，当计数器为0时，则会释放锁。即每执行一个monitorenter对应计数+1，monitorexit对应计数-1。

• 当一个新的线程想要获取该监听器，但该监视器已被其它线程占用时，新线程将会进入入口区。
• 持有者代表当前持有监视器的线程，持有者线程可以多次获取监视器而不会被自己阻塞。
• 等待区是指已进入监视区域但中途由于某种原因（比如等待I/O操作、等待队列消费或生产）而放弃持有监视器的线程。 

ReentrantLock重入锁
　　reentrantLock与synchronized很相似，在JDK1.5之前，前者性能更好，1.6起两者性能就差不多了，甚至在往后的JVM会更倾向于synchronized进行改进，所以建议在用synchronized能解决的情况下就使用synchronized。
　　目前来看，两者主要是表示形式及功能丰富上存在一些差异（reentrantLock以api的方式进行调用，lock()、unlock()通常使用配合 try...finally使用，后者以原生层面上的互斥锁表现），相对原生的synchronized，reentrantLock提供了一些更高级的功能，如获取可中断，设置非/公平锁、条件等（synchronized 是一个非公平性锁）。

如下是JDK中自带的一个经典使用示例（生产者-消费者模式）

• 获取可中断：指在获取锁的过程中，可以响应中断操作。如lockInterruptibly()、 tryLock(long timeout,TimeUnit unit)
• 公平锁：通过new ReentrantLock(true)设置，多线程并发情况下，公平锁倾向于优先将锁分配给等待时间最长的线程。但对于无参的tryLock()公平锁不起作用，只要当前锁可用就被进行分配，而不管其它线程的等待。
• 多个条件Condition ：Condition配合lock一起使用，来实现多条件的锁与唤醒操作。其实它就相当于Object中的wait/notify，只不过使用wait()/notify()时要求当前线程必须先持有对象锁，而condition的使用则没有这个限制，所以更加灵活。

 final Lock lock = new ReentrantLock();
		   final Condition notFull  = lock.newCondition(); 
		   final Condition notEmpty = lock.newCondition(); 

		   final Object[] items = new Object[100];
		   int putptr, takeptr, count;

		   public void put(Object x) throws InterruptedException {
		     lock.lock();
		     try {
		       while (count == items.length) 
		         notFull.await();
		       items[putptr] = x; 
		       if (++putptr == items.length) putptr = 0;
		       ++count;
		       notEmpty.signal();
		     } finally {
		       lock.unlock();
		     }
		   }

		   public Object take() throws InterruptedException {
		     lock.lock();
		     try {
		       while (count == 0) 
		         notEmpty.await();
		       Object x = items[takeptr]; 
		       if (++takeptr == items.length) takeptr = 0;
		       --count;
		       notFull.signal();
		       return x;
		     } finally {
		       lock.unlock();
		     }
		   }