Java基础之多线程
参考博文：
https://link.zhihu.com/?target=https%3A//www.jianshu.com/p/40d4c7aebd66
https://blog.csdn.net/king_kgh/article/details/78213576
https://www.cnblogs.com/felixzh/p/6036074.html
https://www.cnblogs.com/linjiqin/p/3217050.html
https://blog.csdn.net/qq_26545305/article/details/79516610
https://blog.csdn.net/qq_34337272/article/details/81072874
一、线程和进程
概念：进程——资源分配的最小单位，线程——程序执行的最小单位。
我的理解：进程是系统运行的一个程序，线程是进程中的一个执行单元，一个程序至少一个进程，一个进程至少一个线程。
二、多线程重点概念
多线程：一个进程运行时产生了不止一个线程
并行：多个cpu实例或者多台机器同时执行一段处理逻辑，是真正意义上的同时。
并发：通过cpu调度算法，让用户看上去时同时执行，实际上从cpu操作层面不是真正的同时，而是通过cpu时间片的切换实现的。并发往往在场景中有公用的资源，那么针对这个公用的资源往往产生瓶颈，我们会用TPS（吞吐量）或者QPS（每秒查询率）来反应这个系统的处理能力。
线程安全：经常用来描绘一段代码。指在并发的情况之下，该代码经过多线程使用，线程的调度顺序不影响任何结果。这个时候使用多线程，我们只需要关注系统的内存，cpu是不是够用即可。反过来，线程不安全就意味着线程的调度顺序会影响最终结果，如不加事务的转账代码：
void transferMoney(User from, User to, float amount){ to.setMoney(to.getBalance() + amount); from.setMoney(from.getBalance() - amount); }
同步：Java中的同步指的是通过人为的控制和调度，保证共享资源的多线程访问成为线程安全，来保证结果的准确。如上面的代码简单加入@synchronized关键字。在保证结果准确的同时，提高性能，才是优秀的程序。线程安全的优先级高于性能。
线程的状态：初始状态、可运行状态、运行状态、阻塞状态、死亡。
三、多线程的实现方式
多线程的形式上实现方式主要有两种，一种是继承Thread类，一种是实现Runnable接口。本质上实现方式都是来实现线程任务，然后启动线程执行线程任务（这里的线程任务实际上就是run方法）。在这两种的基础上又衍生出几个更丰富的创建线程的方式。
1.继承Thread类
万物皆对象，那么线程也是对象，对象就应该能够抽取其公共特性封装成为类，使用类可以实例化多个对象，那么实现线程的第一种方式就是继承Thread类。继承Thread类是最简单的一种实现线程的方式，通过继承JDK提供的Thread类，重写Thread类的run方法即可，那么当线程运行的时候，就会执行run方法体的内容。demo：
package com.kingh.thread.create; /** * 继承Thread类的方式创建线程 * * @author <a href="https://blog.csdn.net/king_kgh>Kingh</a> * @version 1.0 * @date 2019/3/13 19:19 */ public class CreateThreadDemo1 extends Thread { public CreateThreadDemo1() { // 设置当前线程的名字 this.setName("MyThread"); } @Override public void run() { // 每隔1s中输出一次当前线程的名字 while (true) { // 输出线程的名字，与主线程名称相区分 printThreadInfo(); try { // 线程休眠一秒 Thread.sleep(1000); } catch (Exception e) { throw new RuntimeException(e); } } } public static void main(String[] args) throws Exception { // 注意这里，要调用start方法才能启动线程，不能调用run方法 new CreateThreadDemo1().start(); // 演示主线程继续向下执行 while (true) { printThreadInfo(); Thread.sleep(1000); } } /** * 输出当前线程的信息 */ private static void printThreadInfo() { System.out.println("当前运行的线程名为： " + Thread.currentThread().getName()); } }
结果如下：
当前运行的线程名为： main
当前运行的线程名为： MyThread
当前运行的线程名为： main
当前运行的线程名为： MyThread
当前运行的线程名为： MyThread
当前运行的线程名为： main
注意：在启动线程的时候，并不是调用run方法，而是调用线程类的start方法，线程类会自动执行run方法里的内容，如果直接调用run方法的话这个方法就会被当作一个普通方法被调用，并不会开启线程。
创建多个线程demo：
/** * <p>Title: Thread01</p> * <p>Description: TODO</p> * * @author wanjx * @date 2019年5月26日下午9:56:14 */ public class Thread01 extends Thread{ public Thread01(String name) { // 设置当前线程的名字 this.setName(name); } @Override public void run() { // 每隔1s中输出一次当前线程的名字 while (true) { // 输出线程的名字，与主线程名称相区分 printThreadInfo(); try { // 线程休眠一秒 Thread.sleep(1000); } catch (Exception e) { throw new RuntimeException(e); } } } public static void main(String[] args) throws Exception { // 注意这里，要调用start方法才能启动线程，不能调用run方法 new Thread01("MyThread-01").start(); // 创建多个线程实例，同时执行 new Thread01("MyThread-02").start(); // 演示主线程继续向下执行 while (true) { printThreadInfo(); Thread.sleep(1000); } } /** * 输出当前线程的信息 */ private static void printThreadInfo() { System.out.println("当前运行的线程名为： " + Thread.currentThread().getName()); } } //执行结果为： /* 当前运行的线程名为： main 当前运行的线程名为： MyThread-02 当前运行的线程名为： MyThread-01 当前运行的线程名为： MyThread-02 当前运行的线程名为： main 当前运行的线程名为： MyThread-01 */
2.实现runnable接口
这种方式比较常用，因为接口更加灵活，可以多实现，runnable接口中仅仅定义了一个方法，就是run方法。其实Runnable就是一个线程任务，线程任务和线程的控制分离，实现代码解耦。我们要实现一个线程，可以借助Thread类，Thread类要执行的任务就可以由实现了Runnable接口的类来处理。
demo：
创建线程任务
public class ThreadTask01 implements Runnable { @Override public void run() { // 每隔1s中输出一次当前线程的名字 while (true) { // 输出线程的名字，与主线程名称相区分 printThreadInfo(); try { // 线程休眠一秒 Thread.sleep(1000); } catch (Exception e) { throw new RuntimeException(e); } } } /** * 输出当前线程的信息 */ private static void printThreadInfo() { System.out.println("当前运行的线程名为： " + Thread.currentThread().getName()); } }
在jdk1.8以后，还可以用lambda表达式去创建线程任务
// 使用lambda的形式实例化线程任务类 Runnable task = () -> { while (true) { // 输出线程的名字 printThreadInfo(); } };
创建线程，并执行线程任务
public class Test{ public static void main(String[] args) throws Exception { // 实例化线程任务类 ThreadTask01 task = new ThreadTask01 (); // 创建线程对象,并将线程任务类作为构造方法参数传入 new Thread(task).start(); // 主线程的任务，为了演示多个线程一起执行 while (true) { printThreadInfo(); Thread.sleep(1000); } } /** * 输出当前线程的信息 */ private static void printThreadInfo() { System.out.println("当前运行的线程名为： " + Thread.currentThread().getName()); } }
线程任务和线程的控制分离，那么一个线程任务可以提交给多个线程来执行。这样一来大大提高了代码的灵活性和重用性，相比继承Thread，实现Runnable接口更常用。
3.使用内部类的方式创建
一些简单的业务逻辑不用单独再去创建一个线程任务类，直接重写run方法。demo：
public class CreateThreadDemo6_Anonymous { public static void main(String[] args) { // 基于子类的方式 new Thread() { @Override public void run() { while (true) { printThreadInfo(); } } }.start(); // 基于接口的实现 new Thread(new Runnable() { @Override public void run() { while (true) { printThreadInfo(); } } }).start(); } /** * 输出当前线程的信息 */ private static void printThreadInfo() { System.out.println("当前运行的线程名为： " + Thread.currentThread().getName()); try { Thread.sleep(1000); } catch (Exception e) { throw new RuntimeException(e); } } }
4.利用定时器实现多线程
定时器可以说是一种基于线程的一个工具类，可以定时的来执行某个任务。在Java中实现定时任务有很多种方式，JDK提供了Timer类来帮助开发者创建定时任务，另外也有很多的第三方框架提供了对定时任务的支持，比如Spring的schedule以及著名的quartz等等。
指定时间执行demo：
import java.text.SimpleDateFormat; import java.util.Timer; import java.util.TimerTask; /** * 定时任务 * * @author <a href="https://blog.csdn.net/king_kgh>Kingh</a> * @version 1.0 * @date 2019/3/18 10:04 */ public class CreateThreadDemo9_Timer { private static final SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss"); public static void main(String[] args) throws Exception { // 创建定时器 Timer timer = new Timer(); // 提交计划任务 timer.schedule(new TimerTask() { @Override public void run() { System.out.println("定时任务执行了..."); } }, format.parse("2017-10-11 22:00:00")); } }
间隔时间执行demo：
import java.text.SimpleDateFormat; import java.util.Date; import java.util.Timer; import java.util.TimerTask; /** * 定时任务 * * @author <a href="https://blog.csdn.net/king_kgh>Kingh</a> * @version 1.0 * @date 2019/3/18 10:04 */ public class CreateThreadDemo10_Timer { public static void main(String[] args){ // 创建定时器 Timer timer = new Timer(); // 提交计划任务 timer.schedule(new TimerTask() { @Override public void run() { System.out.println("定时任务执行了..."); } }, new Date(), 1000); } }
5.实现Callable接口通过FutureTask包装器来创建Thread线程
Callable接口也只有一个方法就是call方法，接口定义如下:
public interface Callable<V> { V call（） throws Exception; }
通过实现Callable接口，编写线程任务
public class SomeCallable<V> extends OtherClass implements Callable<V> { @Override public V call() throws Exception { // TODO Auto-generated method stub return null; } }
由Callable对象创建一个FutureTask对象，再将futureTask对象交给线程执行
Callable<V> oneCallable = new SomeCallable<V>(); //由Callable<Integer>创建一个FutureTask<Integer>对象： FutureTask<V> oneTask = new FutureTask<V>(oneCallable); //注释：FutureTask<Integer>是一个包装器，它通过接受Callable<Integer>来创建，它同时实现了Future和Runnable接口。 //由FutureTask<Integer>创建一个Thread对象： Thread oneThread = new Thread(oneTask); oneThread.start(); //至此，一个线程就创建完成了。
6、使用ExecutorService、Callable、Future实现有返回结果的线程
有返回值的任务必须实现Callable接口。类似的，无返回值的任务必须实现Runnable接口。
执行Callable任务后，可以获取一个Future的对象，在该对象上调用get就可以获取到Callable任务返回的Object了。
注意：get方法是阻塞的，即：线程无返回结果，get方法会一直等待。
再结合线程池接口ExecutorService就可以实现传说中有返回结果的多线程了。
demo：
import java.util.concurrent.*; import java.util.Date; import java.util.List; import java.util.ArrayList; /** * 有返回值的线程 */ @SuppressWarnings("unchecked") public class Test { public static void main(String[] args) throws ExecutionException, InterruptedException { System.out.println("----程序开始运行----"); Date date1 = new Date(); int taskSize = 5; // 创建一个线程池 ExecutorService pool = Executors.newFixedThreadPool(taskSize); // 创建多个有返回值的任务 List<Future> list = new ArrayList<Future>(); for (int i = 0; i < taskSize; i++) { Callable c = new MyCallable(i + " "); // 执行任务并获取Future对象 Future f = pool.submit(c); // System.out.println(">>>" + f.get().toString()); list.add(f); } // 关闭线程池 pool.shutdown(); // 获取所有并发任务的运行结果 for (Future f : list) { // 从Future对象上获取任务的返回值，并输出到控制台 System.out.println(">>>" + f.get().toString()); } Date date2 = new Date(); System.out.println("----程序结束运行----，程序运行时间【" + (date2.getTime() - date1.getTime()) + "毫秒】"); } } class MyCallable implements Callable<Object> { private String taskNum; MyCallable(String taskNum) { this.taskNum = taskNum; } public Object call() throws Exception { System.out.println(">>>" + taskNum + "任务启动"); Date dateTmp1 = new Date(); Thread.sleep(1000); Date dateTmp2 = new Date(); long time = dateTmp2.getTime() - dateTmp1.getTime(); System.out.println(">>>" + taskNum + "任务终止"); return taskNum + "任务返回运行结果,当前任务时间【" + time + "毫秒】"; } } /* 代码说明： 上述代码中Executors类，提供了一系列工厂方法用于创建线程池，返回的线程池都实现了ExecutorService接口。 public static ExecutorService newFixedThreadPool(int nThreads) 创建固定数目线程的线程池。 public static ExecutorService newCachedThreadPool() 创建一个可缓存的线程池，调用execute 将重用以前构造的线程（如果线程可用）。如果现有线程没有可用的，则创建一个新线程并添加到池中。终止并从缓存中移除那些已有 60 秒钟未被使用的线程。 public static ExecutorService newSingleThreadExecutor() 创建一个单线程化的Executor。 public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) 创建一个支持定时及周期性的任务执行的线程池，多数情况下可用来替代Timer类。 ExecutoreService提供了submit()方法，传递一个Callable，或Runnable，返回Future。如果Executor后台线程池还没有完成Callable的计算，这调用返回Future对象的get()方法，会阻塞直到计算完成。 */
7.基于线程池的方式
线程在创建和销毁的过程中，是非常耗费性能的，所以，如果有频繁使用和关闭线程的业务，则最好使用线程池的方式实现
demo：
import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; /** * 线程池 * * @author <a href="https://blog.csdn.net/king_kgh>Kingh</a> * @version 1.0 * @date 2019/3/18 10:04 */ public class CreateThreadDemo12_ThreadPool { public static void main(String[] args) throws Exception { // 创建固定大小的线程池 ExecutorService threadPool = Executors.newFixedThreadPool(10); while (true) { // 提交多个线程任务，并执行 threadPool.execute(new Runnable() { @Override public void run() { printThreadInfo(); } }); } } /** * 输出当前线程的信息 */ private static void printThreadInfo() { System.out.println("当前运行的线程名为： " + Thread.currentThread().getName()); try { Thread.sleep(1000); } catch (Exception e) { throw new RuntimeException(e); } } }
执行结果如下：
当前运行的线程名为： pool-1-thread-1 当前运行的线程名为： pool-1-thread-2 当前运行的线程名为： pool-1-thread-4 当前运行的线程名为： pool-1-thread-3 当前运行的线程名为： pool-1-thread-7
四、生产者消费者模型
实际上，准确说应该是“生产者-消费者-仓储”模型，离开了仓储，生产者消费者模型就显得没有说服力了。
对于此模型，应该明确一下几点：
1、生产者仅仅在仓储未满时候生产，仓满则停止生产。
2、消费者仅仅在仓储有产品时候才能消费，仓空则等待。
3、当消费者发现仓储没产品可消费时候会通知生产者生产。
4、生产者在生产出可消费产品时候，应该通知等待的消费者去消费。
demo:
package cn.thread; import java.util.concurrent.BlockingQueue; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.LinkedBlockingQueue; /** * java多线程模拟生产者消费者问题 * * ProducerConsumer是主类，Producer生产者，Consumer消费者，Product产品，Storage仓库 * * @author 林计钦 * @version 1.0 2013-7-24 下午04:49:02 */ public class ProducerConsumer { public static void main(String[] args) { ProducerConsumer pc = new ProducerConsumer(); Storage s = pc.new Storage(); ExecutorService service = Executors.newCachedThreadPool(); Producer p = pc.new Producer("张三", s); Producer p2 = pc.new Producer("李四", s); Consumer c = pc.new Consumer("王五", s); Consumer c2 = pc.new Consumer("老刘", s); Consumer c3 = pc.new Consumer("老林", s); service.submit(p); //service.submit(p2); service.submit(c); service.submit(c2); service.submit(c3); } /** * 消费者 * * @author 林计钦 * @version 1.0 2013-7-24 下午04:53:30 */ class Consumer implements Runnable { private String name; private Storage s = null; public Consumer(String name, Storage s) { this.name = name; this.s = s; } public void run() { try { while (true) { System.out.println(name + "准备消费产品."); Product product = s.pop(); System.out.println(name + "已消费(" + product.toString() + ")."); System.out.println("==============="); Thread.sleep(500); } } catch (InterruptedException e) { e.printStackTrace(); } } } /** * 生产者 * * @author 林计钦 * @version 1.0 2013-7-24 下午04:53:44 */ class Producer implements Runnable { private String name; private Storage s = null; public Producer(String name, Storage s) { this.name = name; this.s = s; } public void run() { try { while (true) { Product product = new Product((int) (Math.random() * 10000)); // 产生0~9999随机整数 System.out.println(name + "准备生产(" + product.toString() + ")."); s.push(product); System.out.println(name + "已生产(" + product.toString() + ")."); System.out.println("==============="); Thread.sleep(500); } } catch (InterruptedException e1) { e1.printStackTrace(); } } } /** * 仓库，用来存放产品 * * @author 林计钦 * @version 1.0 2013-7-24 下午04:54:16 */ public class Storage { BlockingQueue<Product> queues = new LinkedBlockingQueue<Product>(10); /** * 生产 * * @param p * 产品 * @throws InterruptedException */ public void push(Product p) throws InterruptedException { queues.put(p); } /** * 消费 * * @return 产品 * @throws InterruptedException */ public Product pop() throws InterruptedException { return queues.take(); } } /** * 产品 * * @author 林计钦 * @version 1.0 2013-7-24 下午04:54:04 */ public class Product { private int id; public Product(int id) { this.id = id; } public String toString() {// 重写toString方法 return "产品：" + this.id; } } }
执行结果：
张三准备生产(产品：3359). 张三已生产(产品：3359). =============== 老刘准备消费产品. 王五已消费(产品：3359). =============== 王五准备消费产品. 张三准备生产(产品：1863). 张三已生产(产品：1863). =============== 老林已消费(产品：1863). =============== 老林准备消费产品. 张三准备生产(产品：5424). 张三已生产(产品：5424). 老刘已消费(产品：5424). =============== =============== 张三准备生产(产品：6290). 张三已生产(产品：6290). =============== 老刘准备消费产品. 王五已消费(产品：6290). =============== 张三准备生产(产品：990). 张三已生产(产品：990). =============== 老林已消费(产品：990). =============== 王五准备消费产品. 张三准备生产(产品：1971). 老林准备消费产品. 老刘已消费(产品：1971). =============== 张三已生产(产品：1971). =============== 张三准备生产(产品：5622). 老刘准备消费产品. 张三已生产(产品：5622). =============== 王五已消费(产品：5622). =============== 王五准备消费产品. 张三准备生产(产品：6570). 张三已生产(产品：6570). =============== 老林已消费(产品：6570). =============== 老林准备消费产品. 张三准备生产(产品：17). 老刘已消费(产品：17). =============== 张三已生产(产品：17). =============== 老刘准备消费产品. 张三准备生产(产品：7962). 张三已生产(产品：7962). =============== 王五已消费(产品：7962). =============== 王五准备消费产品. 张三准备生产(产品：3200). 张三已生产(产品：3200). =============== 老林已消费(产品：3200). =============== 老林准备消费产品. 张三准备生产(产品：7234). 张三已生产(产品：7234). =============== 老刘已消费(产品：7234). =============== 老刘准备消费产品. 张三准备生产(产品：6486). 张三已生产(产品：6486). =============== 王五已消费(产品：6486). =============== 张三准备生产(产品：5436). 王五准备消费产品. 王五已消费(产品：5436). ===============
五、怎样将保证线程安全
1.线程的安全等级：
1、不可变 在java语言中，不可变的对象一定是线程安全的，无论是对象的方法实现还是方法的调用者，都不需要再采取任何的线程安全保障措施。如final关键字修饰的数据不可修改，可靠性最高。 2、绝对线程安全 绝对的线程安全完全满足Brian GoetZ给出的线程安全的定义，这个定义其实是很严格的，一个类要达到“不管运行时环境如何，调用者都不需要任何额外的同步措施”通常需要付出很大的代价。 3、相对线程安全 相对线程安全就是我们通常意义上所讲的一个类是“线程安全”的。 它需要保证对这个对象单独的操作是线程安全的，我们在调用的时候不需要做额外的保障措施，但是对于一些特定顺序的连续调用，就可能需要在调用端使用额外的同步手段来保证调用的正确性。 在java语言中，大部分的线程安全类都属于相对线程安全的，例如Vector、HashTable、Collections的synchronizedCollection（）方法保证的集合。 4、线程兼容 线程兼容就是我们通常意义上所讲的一个类不是线程安全的。 线程兼容是指对象本身并不是线程安全的，但是可以通过在调用端正确地使用同步手段来保证对象在并发环境下可以安全地使用。Java API中大部分的类都是属于线程兼容的。如与前面的Vector和HashTable相对应的集合类ArrayList和HashMap等。 5、线程对立 线程对立是指无论调用端是否采取了同步错误，都无法在多线程环境中并发使用的代码。由于java语言天生就具有多线程特性，线程对立这种排斥多线程的代码是很少出现的。 一个线程对立的例子是Thread类的supend()和resume()方法。如果有两个线程同时持有一个线程对象，一个尝试去中断线程，另一个尝试去恢复线程，如果并发进行的话，无论调用时是否进行了同步，目标线程都有死锁风险。正因此如此，这两个方法已经被废弃啦。
2.实现线程安全的手段
保证线程安全以是否需要同步手段分类，分为同步方案和无需同步方案。
1）、互斥同步
互斥同步是最常见的一种并发正确性保障手段。
同步是指在多线程并发访问共享数据时，保证共享数据在同一时刻只被一个线程使用（同一时刻，只有一个线程在操作共享数据）。而互斥是实现同步的一种手段，临界区、互斥量和信号量都是主要的互斥实现方式。
因此，在这4个字里面，互斥是因，同步是果；互斥是方法，同步是目的。
在java中，最基本的互斥同步手段就是synchronized关键字，synchronized关键字编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码质量，这两个字节码指令都需要一个reference类型的参数来指明要锁定和解锁的对象。
此外，ReentrantLock也是通过互斥来实现同步。在基本用法上，ReentrantLock与synchronized很相似，他们都具备一样的线程重入特性。
互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题，因此这种同步也成为阻塞同步。从处理问题的方式上说，互斥同步属于一种悲观的并发策略，总是认为只要不去做正确地同步措施（例如加锁），那就肯定会出现问题，无论共享数据是否真的会出现竞争，它都要进行加锁。
2）、非阻塞同步
随着硬件指令集的发展，出现了基于冲突检测的乐观并发策略，通俗地说，就是先进行操作，如果没有其他线程争用共享数据，那操作就成功了；
如果共享数据有争用，产生了冲突，那就再采用其他的补偿措施。（最常见的补偿错误就是不断地重试，直到成功为止），这种乐观的并发策略的许多实现都不需要把线程挂起，因此这种同步操作称为非阻塞同步。
非阻塞的实现CAS（compareandswap）：CAS指令需要有3个操作数，分别是内存地址（在java中理解为变量的内存地址，用V表示）、旧的预期值（用A表示）和新值（用B表示）。
CAS指令执行时，CAS指令指令时，当且仅当V处的值符合旧预期值A时，处理器用B更新V处的值，否则它就不执行更新，但是无论是否更新了V处的值，都会返回V的旧值，上述的处理过程是一个原子操作。
CAS缺点：
ABA问题：因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。
ABA问题的解决思路就是使用版本号。在变量前面追加版本号，每次变量更新的时候把版本号加一，那么A-B-A就变成了1A-2B-3C。JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。
这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
3）、无需同步方案
要保证线程安全，并不是一定就要进行同步，两者没有因果关系。同步只是保证共享数据争用时的正确性的手段，如果一个方法本来就不涉及共享数据，那它自然就无需任何同步操作去保证正确性，因此会有一些代码天生就是线程安全的。
1）可重入代码
可重入代码（ReentrantCode）也称为纯代码（Pure Code），可以在代码执行的任何时刻中断它，转而去执行另外一段代码，而在控制权返回后，原来的程序不会出现任何错误。所有的可重入代码都是线程安全的，但是并非所有的线程安全的代码都是可重入的。
可重入代码的特点是不依赖存储在堆上的数据和公用的系统资源、用到的状态量都是由参数中传入、不调用 非可重入的方法等。
（类比：synchronized拥有锁重入的功能，也就是在使用synchronized时，当一个线程得到一个对象锁后，再次请求此对象锁时时可以再次得到该对象的锁）
2）线程本地存储
如果一段代码中所需的数据必须与其他代码共享，那就看看这些共享数据的代码是否能保证在同一个线程中执行？如果能保证，我们就可以把共享数据的可见范围限制在同一个线程之内。这样无需同步也能保证线程之间不出现数据的争用问题。
符合这种特点的应用并不少见，大部分使用消费队列的架构模式（如“生产者-消费者”模式）都会将产品的消费过程尽量在一个线程中消费完。
其中最重要的一个应用实例就是经典的Web交互模型中的“一个请求对应一个服务器线程（Thread-per-Request）”的处理方式，这种处理方式的广泛应用使得很多Web服务器应用都可以使用线程本地存储来解决线程安全问题。
六、悲观锁和乐观锁
悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
乐观锁
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
两种锁的使用场景
从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。
乐观锁常见的两种实现方式
乐观锁一般会使用版本号机制或CAS算法实现。
1. 版本号机制
一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
举一个简单的例子：
假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。
操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。
在操作员 A 操作的过程中，操作员B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 当前最后更新的version与操作员第一次的版本号相等 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。
这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。
2. CAS算法
即compare and swap（比较与交换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。CAS算法涉及到三个操作数
需要读写的内存值 V
进行比较的值 A
拟写入的新值 B
当且仅当 V 的值等于 A时，CAS通过原子方式用新值B来更新V的值，否则不会执行任何操作（比较和替换是一个原子操作）。一般情况下是一个自旋操作，即不断的重试。
乐观锁的缺点
ABA 问题是乐观锁一个常见的问题
1 ABA 问题
如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 "ABA"问题。
JDK 1.5 以后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
2 循环时间长开销大
自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给CPU带来非常大的执行开销。 如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline）,使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPU pipeline flush），从而提高CPU的执行效率。
3 只能保证一个共享变量的原子操作
CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操作。
CAS与synchronized的使用情景
简单的来说CAS适用于写比较少的情况下（多读场景，冲突一般较少），synchronized适用于写比较多的情况下（多写场景，冲突一般较多）
对于资源竞争较少（线程冲突较轻）的情况，使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源；而CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。
对于资源竞争严重（线程冲突严重）的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源，效率低于synchronized。
补充： Java并发编程这个领域中synchronized关键字一直都是元老级的角色，很久之前很多人都会称它为 “重量级锁” 。但是，在JavaSE 1.6之后进行了主要包括为了减少获得锁和释放锁带来的性能消耗而引入的 偏向锁 和 轻量级锁 以及其它各种优化之后变得在某些情况下并不是那么重了。synchronized的底层实现主要依靠 Lock-Free 的队列，基本思路是 自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。
七、ReentrantLock和synchoronized
这个内容转载自：https://www.ibm.com/developerworks/cn/java/j-jtp10264/index.html
多线程和并发性并不是什么新内容，但是 Java 语言设计中的创新之一就是，它是第一个直接把跨平台线程模型和正规的内存模型集成到语言中的主流语言。核心类库包含一个 Thread 类，可以用它来构建、启动和操纵线程，Java 语言包括了跨线程传达并发性约束的构造 —— synchronized 和 volatile 。在简化与平台无关的并发类的开发的同时，它决没有使并发类的编写工作变得更繁琐，只是使它变得更容易了。
synchronized 快速回顾
把代码块声明为 synchronized，有两个重要后果，通常是指该代码具有 原子性（atomicity）和 可见性（visibility）。原子性意味着一个线程一次只能执行由一个指定监控对象（lock）保护的代码，从而防止多个线程在更新共享状态时相互冲突。可见性则更为微妙；它要对付内存缓存和编译器优化的各种反常行为。一般来说，线程以某种不必让其他线程立即可以看到的方式（不管这些线程在寄存器中、在处理器特定的缓存中，还是通过指令重排或者其他编译器优化），不受缓存变量值的约束，但是如果开发人员使用了同步，如下面的代码所示，那么运行库将确保某一线程对变量所做的更新先于对现有 synchronized 块所进行的更新，当进入由同一监控器（lock）保护的另一个 synchronized 块时，将立刻可以看到这些对变量所做的更新。类似的规则也存在于 volatile 变量上。（有关同步和 Java 内存模型的内容，请参阅 参考资料。）
|
1
2
3
|
synchronized (lockObject) { // update object state} |
所以，实现同步操作需要考虑安全更新多个共享变量所需的一切，不能有争用条件，不能破坏数据（假设同步的边界位置正确），而且要保证正确同步的其他线程可以看到这些变量的最新值。通过定义一个清晰的、跨平台的内存模型（该模型在 JDK 5.0 中做了修改，改正了原来定义中的某些错误），通过遵守下面这个简单规则，构建“一次编写，随处运行”的并发类是有可能的：
不论什么时候，只要您将编写的变量接下来可能被另一个线程读取，或者您将读取的变量最后是被另一个线程写入的，那么您必须进行同步。
不过现在好了一点，在最近的 JVM 中，没有争用的同步（一个线程拥有锁的时候，没有其他线程企图获得锁）的性能成本还是很低的。（也不总是这样；早期 JVM 中的同步还没有优化，所以让很多人都这样认为，但是现在这变成了一种误解，人们认为不管是不是争用，同步都有很高的性能成本。）
对 synchronized 的改进
如此看来同步相当好了，是么？那么为什么 JSR 166 小组花了这么多时间来开发 java.util.concurrent.lock 框架呢？答案很简单－同步是不错，但它并不完美。它有一些功能性的限制 —— 它无法中断一个正在等候获得锁的线程，也无法通过轮询得到锁，如果不想等下去，也就没法得到锁。同步还要求锁的释放只能在与获得锁所在的堆栈帧相同的堆栈帧中进行，多数情况下，这没问题（而且与异常处理交互得很好），但是，确实存在一些非块结构的锁定更合适的情况。
ReentrantLock 类
java.util.concurrent.lock 中的 Lock 框架是锁定的一个抽象，它允许把锁定的实现作为 Java 类，而不是作为语言的特性来实现。这就为 Lock 的多种实现留下了空间，各种实现可能有不同的调度算法、性能特性或者锁定语义。 ReentrantLock 类实现了 Lock ，它拥有与 synchronized 相同的并发性和内存语义，但是添加了类似轮询锁、定时锁等候和可中断锁等候的一些特性。此外，它还提供了在激烈争用情况下更佳的性能。（换句话说，当许多线程都想访问共享资源时，JVM 可以花更少的时候来调度线程，把更多时间用在执行线程上。）
reentrant 锁意味着什么呢？简单来说，它有一个与锁相关的获取计数器，如果拥有锁的某个线程再次得到锁，那么获取计数器就加1，然后锁需要被释放两次才能获得真正释放。这模仿了 synchronized 的语义；如果线程进入由线程已经拥有的监控器保护的 synchronized 块，就允许线程继续进行，当线程退出第二个（或者后续） synchronized 块的时候，不释放锁，只有线程退出它进入的监控器保护的第一个 synchronized 块时，才释放锁。
在查看清单 1 中的代码示例时，可以看到 Lock 和 synchronized 有一点明显的区别 —— lock 必须在 finally 块中释放。否则，如果受保护的代码将抛出异常，锁就有可能永远得不到释放！这一点区别看起来可能没什么，但是实际上，它极为重要。忘记在 finally 块中释放锁，可能会在程序中留下一个定时炸弹，当有一天炸弹爆炸时，您要花费很大力气才有找到源头在哪。而使用同步，JVM 将确保锁会获得自动释放。
清单 1. 用 ReentrantLock 保护代码块。
|
1
2
3
4
5
6
7
8
|
Lock lock = new ReentrantLock();lock.lock();try { // update object state}finally { lock.unlock(); } |
除此之外，与目前的 synchronized 实现相比，争用下的 ReentrantLock 实现更具可伸缩性。（在未来的 JVM 版本中，synchronized 的争用性能很有可能会获得提高。）这意味着当许多线程都在争用同一个锁时，使用 ReentrantLock 的总体开支通常要比 synchronized 少得多。
比较 ReentrantLock 和 synchronized 的可伸缩性
Tim Peierls 用一个简单的线性全等伪随机数生成器（PRNG）构建了一个简单的评测，用它来测量 synchronized 和 Lock 之间相对的可伸缩性。这个示例很好，因为每次调用 nextRandom() 时，PRNG 都确实在做一些工作，所以这个基准程序实际上是在测量一个合理的、真实的 synchronized 和 Lock 应用程序，而不是测试纯粹纸上谈兵或者什么也不做的代码（就像许多所谓的基准程序一样。）
在这个基准程序中，有一个 PseudoRandom 的接口，它只有一个方法 nextRandom(int bound) 。该接口与 java.util.Random类的功能非常类似。因为在生成下一个随机数时，PRNG 用最新生成的数字作为输入，而且把最后生成的数字作为一个实例变量来维护，其重点在于让更新这个状态的代码段不被其他线程抢占，所以我要用某种形式的锁定来确保这一点。（java.util.Random 类也可以做到这点。）我们为 PseudoRandom 构建了两个实现；一个使用 syncronized，另一个使用 java.util.concurrent.ReentrantLock 。驱动程序生成了大量线程，每个线程都疯狂地争夺时间片，然后计算不同版本每秒能执行多少轮。图 1 和 图 2 总结了不同线程数量的结果。这个评测并不完美，而且只在两个系统上运行了（一个是双 Xeon 运行超线程 Linux，另一个是单处理器 Windows 系统），但是，应当足以表现 synchronized 与 ReentrantLock 相比所具有的伸缩性优势了。
图 1. synchronized 和 Lock 的吞吐率，单 CPU
图 2. synchronized 和 Lock 的吞吐率（标准化之后），4 个 CPU
图 1 和图 2 中的图表以每秒调用数为单位显示了吞吐率，把不同的实现调整到 1 线程 synchronized 的情况。每个实现都相对迅速地集中在某个稳定状态的吞吐率上，该状态通常要求处理器得到充分利用，把大多数的处理器时间都花在处理实际工作（计算机随机数）上，只有小部分时间花在了线程调度开支上。您会注意到，synchronized 版本在处理任何类型的争用时，表现都相当差，而 Lock 版本在调度的开支上花的时间相当少，从而为更高的吞吐率留下空间，实现了更有效的 CPU 利用。
条件变量
根类 Object 包含某些特殊的方法，用来在线程的 wait() 、 notify() 和 notifyAll() 之间进行通信。这些是高级的并发性特性，许多开发人员从来没有用过它们 —— 这可能是件好事，因为它们相当微妙，很容易使用不当。幸运的是，随着 JDK 5.0 中引入 java.util.concurrent ，开发人员几乎更加没有什么地方需要使用这些方法了。
通知与锁定之间有一个交互 —— 为了在对象上 wait 或 notify ，您必须持有该对象的锁。就像 Lock 是同步的概括一样， Lock框架包含了对 wait 和 notify 的概括，这个概括叫作 条件（Condition） 。 Lock 对象则充当绑定到这个锁的条件变量的工厂对象，与标准的 wait 和 notify 方法不同，对于指定的 Lock ，可以有不止一个条件变量与它关联。这样就简化了许多并发算法的开发。例如， 条件（Condition） 的 Javadoc 显示了一个有界缓冲区实现的示例，该示例使用了两个条件变量，“not full”和“not empty”，它比每个 lock 只用一个 wait 设置的实现方式可读性要好一些（而且更有效）。 Condition 的方法与 wait 、 notify 和 notifyAll 方法类似，分别命名为 await 、 signal 和 signalAll ，因为它们不能覆盖 Object 上的对应方法。
这不公平
如果查看 Javadoc，您会看到， ReentrantLock 构造器的一个参数是 boolean 值，它允许您选择想要一个 公平（fair）锁，还是一个 不公平（unfair）锁。公平锁使线程按照请求锁的顺序依次获得锁；而不公平锁则允许直接获取锁，在这种情况下，线程有时可以比先请求锁的其他线程先得到锁。
为什么我们不让所有的锁都公平呢？毕竟，公平是好事，不公平是不好的，不是吗？（当孩子们想要一个决定时，总会叫嚷“这不公平”。我们认为公平非常重要，孩子们也知道。）在现实中，公平保证了锁是非常健壮的锁，有很大的性能成本。要确保公平所需要的记帐（bookkeeping）和同步，就意味着被争夺的公平锁要比不公平锁的吞吐率更低。作为默认设置，应当把公平设置为 false ，除非公平对您的算法至关重要，需要严格按照线程排队的顺序对其进行服务。
那么同步又如何呢？内置的监控器锁是公平的吗？答案令许多人感到大吃一惊，它们是不公平的，而且永远都是不公平的。但是没有人抱怨过线程饥渴，因为 JVM 保证了所有线程最终都会得到它们所等候的锁。确保统计上的公平性，对多数情况来说，这就已经足够了，而这花费的成本则要比绝对的公平保证的低得多。所以，默认情况下 ReentrantLock 是“不公平”的，这一事实只是把同步中一直是事件的东西表面化而已。如果您在同步的时候并不介意这一点，那么在 ReentrantLock 时也不必为它担心。
图 3 和图 4 包含与 图 1和 图 2 相同的数据，只是添加了一个数据集，用来进行随机数基准检测，这次检测使用了公平锁，而不是默认的协商锁。正如您能看到的，公平是有代价的。如果您需要公平，就必须付出代价，但是请不要把它作为您的默认选择。
图 3. 使用 4 个 CPU 时的同步、协商锁和公平锁的相对吞吐率
图 4. 使用 1 个 CPU 时的同步、协商和公平锁的相对吞吐率
处处都好？
看起来 ReentrantLock 无论在哪方面都比 synchronized 好 —— 所有 synchronized 能做的，它都能做，它拥有与 synchronized 相同的内存和并发性语义，还拥有 synchronized 所没有的特性，在负荷下还拥有更好的性能。那么，我们是不是应当忘记 synchronized ，不再把它当作已经已经得到优化的好主意呢？或者甚至用 ReentrantLock 重写我们现有的 synchronized 代码？实际上，几本 Java 编程方面介绍性的书籍在它们多线程的章节中就采用了这种方法，完全用 Lock 来做示例，只把 synchronized 当作历史。但我觉得这是把好事做得太过了。
还不要抛弃 synchronized
虽然 ReentrantLock 是个非常动人的实现，相对 synchronized 来说，它有一些重要的优势，但是我认为急于把 synchronized 视若敝屣，绝对是个严重的错误。 java.util.concurrent.lock 中的锁定类是用于高级用户和高级情况的工具 。一般来说，除非您对 Lock 的某个高级特性有明确的需要，或者有明确的证据（而不是仅仅是怀疑）表明在特定情况下，同步已经成为可伸缩性的瓶颈，否则还是应当继续使用 synchronized。
为什么我在一个显然“更好的”实现的使用上主张保守呢？因为对于 java.util.concurrent.lock 中的锁定类来说，synchronized 仍然有一些优势。比如，在使用 synchronized 的时候，不可能忘记释放锁；在退出 synchronized 块时，JVM 会为您做这件事。您很容易忘记用 finally 块释放锁，这对程序非常有害。您的程序能够通过测试，但会在实际工作中出现死锁，那时会很难指出原因（这也是为什么根本不让初级开发人员使用 Lock 的一个好理由。）
另一个原因是因为，当 JVM 用 synchronized 管理锁定请求和释放时，JVM 在生成线程转储时能够包括锁定信息。这些对调试非常有价值，因为它们能标识死锁或者其他异常行为的来源。 Lock 类只是普通的类，JVM 不知道具体哪个线程拥有 Lock 对象。而且，几乎每个开发人员都熟悉 synchronized，它可以在 JVM 的所有版本中工作。在 JDK 5.0 成为标准（从现在开始可能需要两年）之前，使用 Lock 类将意味着要利用的特性不是每个 JVM 都有的，而且不是每个开发人员都熟悉的。
什么时候选择用 ReentrantLock 代替 synchronized
既然如此，我们什么时候才应该使用 ReentrantLock 呢？答案非常简单 —— 在确实需要一些 synchronized 所没有的特性的时候，比如时间锁等候、可中断锁等候、无块结构锁、多个条件变量或者轮询锁。 ReentrantLock 还具有可伸缩性的好处，应当在高度争用的情况下使用它，但是请记住，大多数 synchronized 块几乎从来没有出现过争用，所以可以把高度争用放在一边。我建议用 synchronized 开发，直到确实证明 synchronized 不合适，而不要仅仅是假设如果使用 ReentrantLock “性能会更好”。请记住，这些是供高级用户使用的高级工具。（而且，真正的高级用户喜欢选择能够找到的最简单工具，直到他们认为简单的工具不适用为止。）。一如既往，首先要把事情做好，然后再考虑是不是有必要做得更快。
结束语
Lock 框架是同步的兼容替代品，它提供了 synchronized 没有提供的许多特性，它的实现在争用下提供了更好的性能。但是，这些明显存在的好处，还不足以成为用 ReentrantLock 代替 synchronized 的理由。相反，应当根据您是否 需要ReentrantLock 的能力来作出选择。大多数情况下，您不应当选择它 —— synchronized 工作得很好，可以在所有 JVM 上工作，更多的开发人员了解它，而且不太容易出错。只有在真正需要 Lock 的时候才用它。在这些情况下，您会很高兴拥有这款工具。
浙公网安备 33010602011771号