Java多线程

同步和异步

 

同步，Synchronous，即调用方法开始，一旦调用就必须等待方法执行完返回才能继续下面的操作。

举个例子，你去银行ATM取钱，你必须等到ATM吐完钱你拿到钱取完卡你才能离开。

 

异步，Asynchronous，即不关心方法执行的过程，触发要调用的方法就继续执行下面的操作，不会像同步那样阻塞直要到方法完成才继续。

举个例子，你这次要取钱，数量较大，你直接电话或者APP预约银行说你要取多少万现金，这段时间银行会为你准备钱，而这与你都没什么关系，然后你只要按预定的时候去取就行了，对你于而言，你们是触发了一个异步动作而已。

 

并发和并行

 

并发，Concurrency，即一段时间内多个任务在执行，但不一定是同时在执行，它们可能是交替在运行，也有可能是串行运行的。

 

并行，Parallelism，这个就是多个任务在同时执行，可以理解为并发里面有一部分任务在并行执行。

 

单核CPU不会有并行操作，应为一个CPU一次只能执行一条指令，并行操作只存在于多核CPU中。

 

阻塞和非阻塞

 

阻塞，Blocking，如果一个线程占用了一个公共资源而没有释放对它的锁，另外别的一些线程想要继续执行就只能等它释放锁，这时候就造成阻塞了。

 

非阻塞，Non-Blocking，就是没有阻塞，线程可以自由运行，没有锁定公共资源，不相互阻塞运行。

 

实现多线程的3种方式

 

1、继承Thread类

 

看jdk源码可以发现，Thread类其实是实现了Runnable接口的一个实例，继承Thread类后需要重写run方法并通过start方法启动线程。

 

继承Thread类耦合性太强了，因为java只能单继承，所以不利于扩展。

 

2、实现Runnable接口

 

通过实现Runnable接口并重写run方法，并把Runnable实例传给Thread对象，Thread的start方法调用run方法再通过调用Runnable实例的run方法启动线程。

 

所以如果一个类继承了另外一个父类，此时要实现多线程就不能通过继承Thread的类实现。

 

3、实现Callable接口

 

通过实现Callable接口并重写call方法，并把Callable实例传给FutureTask对象，再把FutureTask对象传给Thread对象。它与Thread、Runnable最大的不同是Callable能返回一个异步处理的结果Future对象并能抛出异常，而其他两种不能。

 

示例代码

 

 

结果输出：

 

Thread1 running...

Thread2 running...

Thread3 running...

name:java,age:22

 

 

上图是一个线程的生命周期状态流转图，很清楚的描绘了一个线程从创建到终止的过程。

 

这些状态的枚举值都定义在java.lang.Thread.State下

 

 

NEW：毫无疑问表示的是刚创建的线程，还没有开始启动。

 

RUNNABLE:  表示线程已经触发start()方式调用，线程正式启动，线程处于运行中状态。

 

BLOCKED：表示线程阻塞，等待获取锁，如碰到synchronized、lock等关键字等占用临界区的情况，一旦获取到锁就进行RUNNABLE状态继续运行。

 

WAITING：表示线程处于无限制等待状态，等待一个特殊的事件来重新唤醒，如通过wait()方法进行等待的线程等待一个notify()或者notifyAll()方法，通过join()方法进行等待的线程等待目标线程运行结束而唤醒，一旦通过相关事件唤醒线程，线程就进入了RUNNABLE状态继续运行。

 

TIMED_WAITING：表示线程进入了一个有时限的等待，如sleep(3000)，等待3秒后线程重新进行RUNNABLE状态继续运行。

 

TERMINATED：表示线程执行完毕后，进行终止状态。

 

需要注意的是，一旦线程通过start方法启动后就再也不能回到初始NEW状态，线程终止后也不能再回到RUNNABLE状态。

 

 

死锁、活锁、饥饿是关于多线程是否活跃出现的运行阻塞障碍问题，如果线程出现了这三种情况，即线程不再活跃，不能再正常地执行下去了。

 

死锁

 

死锁是多线程中最差的一种情况，多个线程相互占用对方的资源的锁，而又相互等对方释放锁，此时若无外力干预，这些线程则一直处理阻塞的假死状态，形成死锁。

 

举个例子，A同学抢了B同学的钢笔，B同学抢了A同学的书，两个人都相互占用对方的东西，都在让对方先还给自己自己再还，这样一直争执下去等待对方还而又得不到解决，老师知道此事后就让他们相互还给对方，这样在外力的干预下他们才解决，当然这只是个例子没有老师他们也能很好解决，计算机不像人如果发现这种情况没有外力干预还是会一直阻塞下去的。

 

活锁

 

活锁这个概念大家应该很少有人听说或理解它的概念，而在多线程中这确实存在。活锁恰恰与死锁相反，死锁是大家都拿不到资源都占用着对方的资源，而活锁是拿到资源却又相互释放不执行。当多线程中出现了相互谦让，都主动将资源释放给别的线程使用，这样这个资源在多个线程之间跳动而又得不到执行，这就是活锁。

 

饥饿

 

我们知道多线程执行中有线程优先级这个东西，优先级高的线程能够插队并优先执行，这样如果优先级高的线程一直抢占优先级低线程的资源，导致低优先级线程无法得到执行，这就是饥饿。当然还有一种饥饿的情况，一个线程一直占着一个资源不放而导致其他线程得不到执行，与死锁不同的是饥饿在以后一段时间内还是能够得到执行的，如那个占用资源的线程结束了并释放了资源。

 

无锁

 

无锁，即没有对资源进行锁定，即所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。无锁典型的特点就是一个修改操作在一个循环内进行，线程会不断的尝试修改共享资源，如果没有冲突就修改成功并退出否则就会继续下一次循环尝试。所以，如果有多个线程修改同一个值必定会有一个线程能修改成功，而其他修改失败的线程会不断重试直到修改成功。之前的文章我介绍过JDK的CAS原理及应用即是无锁的实现。

 

可以看出，无锁是一种非常良好的设计，它不会出现线程出现的跳跃性问题，锁使用不当肯定会出现系统性能问题，虽然无锁无法全面代替有锁，但无锁在某些场合下是非常高效的。

 

多线程死锁在java程序员笔试的时候时有遇见，死锁概念在之前的文章有介绍，大家应该也都明白它的概念，不清楚的去翻看历史文章吧。

 

下面是一个多线程死锁的例子

 

 

输出

 

thread1 get lock1

thread2 get lock2

 

两个线程相互得到锁1，锁2，然后线程1等待线程2释放锁2，线程2等待线程1释放锁1，两者各不相互，这样形成死锁。

 

那么如何避免和解决死锁问题呢？

 

1、按顺序加锁

 

上个例子线程间加锁的顺序各不一致，导致死锁，如果每个线程都按同一个的加锁顺序这样就不会出现死锁。

 

2、获取锁时限

 

每个获取锁的时候加上个时限，如果超过某个时间就放弃获取锁之类的。

 

3、死锁检测

 

按线程间获取锁的关系检测线程间是否发生死锁，如果发生死锁就执行一定的策略，如终断线程或回滚操作等。

 

 

 

什么是线程池？

 

很简单，简单看名字就知道是装有线程的池子，我们可以把要执行的多线程交给线程池来处理，和连接池的概念一样，通过维护一定数量的线程池来达到多个线程的复用。

 

线程池的好处

 

我们知道不用线程池的话，每个线程都要通过new Thread(xxRunnable).start()的方式来创建并运行一个线程，线程少的话这不会是问题，而真实环境可能会开启多个线程让系统和程序达到最佳效率，当线程数达到一定数量就会耗尽系统的CPU和内存资源，也会造成GC频繁收集和停顿，因为每次创建和销毁一个线程都是要消耗系统资源的，如果为每个任务都创建线程这无疑是一个很大的性能瓶颈。所以，线程池中的线程复用极大节省了系统资源，当线程一段时间不再有任务处理时它也会自动销毁，而不会长驻内存。

 

线程池核心类

 

在java.util.concurrent包中我们能找到线程池的定义，其中ThreadPoolExecutor是我们线程池核心类，首先看看线程池类的主要参数有哪些。

 

• corePoolSize：线程池的核心大小，也可以理解为最小的线程池大小。

• maximumPoolSize：最大线程池大小。

• keepAliveTime：空余线程存活时间，指的是超过corePoolSize的空余线程达到多长时间才进行销毁。

• unit：销毁时间单位。

• workQueue：存储等待执行线程的工作队列。

• threadFactory：创建线程的工厂，一般用默认即可。

• handler：拒绝策略，当工作队列、线程池全已满时如何拒绝新任务，默认抛出异常。

 

线程池工作流程

 

1、如果线程池中的线程小于corePoolSize时就会创建新线程直接执行任务。

2、如果线程池中的线程大于corePoolSize时就会暂时把任务存储到工作队列workQueue中等待执行。

3、如果工作队列workQueue也满时：当线程数小于最大线程池数maximumPoolSize时就会创建新线程来处理，而线程数大于等于最大线程池数maximumPoolSize时就会执行拒绝策略。

 

线程池分类

 

Executors是jdk里面提供的创建线程池的工厂类，它默认提供了4种常用的线程池应用，而不必我们去重复构造。

 

• newFixedThreadPool

   

   

  固定线程池，核心线程数和最大线程数固定相等，而空闲存活时间为0毫秒，说明此参数也无意义，工作队列为最大为Integer.MAX_VALUE大小的阻塞队列。当执行任务时，如果线程都很忙，就会丢到工作队列等有空闲线程时再执行，队列满就执行默认的拒绝策略。

 

 

• newCachedThreadPool

       

       带缓冲线程池，从构造看核心线程数为0，最大线程数为Integer最大值大小，超过0个的空闲线程在60秒后销毁，SynchronousQueue这是一个直接提交的队列，意味着每个新任务都会有线程来执行，如果线程池有可用线程则执行任务，没有的话就创建一个来执行，线程池中的线程数不确定，一般建议执行速度较快较小的线程，不然这个最大线程池边界过大容易造成内存溢出。

 

 

• newSingleThreadExecutor

       

       单线程线程池，核心线程数和最大线程数均为1，空闲线程存活0毫秒同样无意思，意味着每次只执行一个线程，多余的先存储到工作队列，一个一个执行，保证了线程的顺序执行。

 

 

• newScheduledThreadPool

   

  调度线程池，即按一定的周期执行任务，即定时任务，对ThreadPoolExecutor进行了包装而已。

   

 

拒绝策略

 

• AbortPolicy

 

      简单粗暴，直接抛出拒绝异常，这也是默认的拒绝策略。

 

 

• CallerRunsPolicy

   

        

       如果线程池未关闭，则会在调用者线程中直接执行新任务，这会导致主线程提交线程性能变慢。

 

 

• DiscardPolicy

 

       从方法看没做任务操作，即表示不处理新任务，即丢弃。

 

 

• DiscardOldestPolicy

 

       抛弃最老的任务，就是从队列取出最老的任务然后放入新的任务进行执行。        

 

 

如何提交线程

 

如可以先随便定义一个固定大小的线程池

ExecutorService es = Executors.newFixedThreadPool(3);

 

提交一个线程

es.submit(xxRunnble);

es.execute(xxRunnble);

 

submit和execute分别有什么区别呢？

execute没有返回值，如果不需要知道线程的结果就使用execute方法，性能会好很多。

submit返回一个Future对象，如果想知道线程结果就使用submit提交，而且它能在主线程中通过Future的get方法捕获线程中的异常。

 

如何关闭线程池

 

es.shutdown(); 

不再接受新的任务，之前提交的任务等执行结束再关闭线程池。

 

es.shutdownNow();

不再接受新的任务，试图停止池中的任务再关闭线程池，返回所有未处理的线程list列表。

 

 

 

原子性、可见性、有序性是多线程编程中最重要的几个知识点，由于多线程情况复杂，如何让每个线程能看到正确的结果，这是非常重要的。

 

原子性

 

原子性是指一个线程的操作是不能被其他线程打断，同一时间只有一个线程对一个变量进行操作。在多线程情况下，每个线程的执行结果不受其他线程的干扰，比如说多个线程同时对同一个共享成员变量n++100次，如果n初始值为0，n最后的值应该是100，所以说它们是互不干扰的，这就是传说的中的原子性。但n++并不是原子性的操作，要使用AtomicInteger保证原子性。

 

可见性

 

可见性是指某个线程修改了某一个共享变量的值，而其他线程是否可以看见该共享变量修改后的值。在单线程中肯定不会有这种问题，单线程读到的肯定都是最新的值，而在多线程编程中就不一定了。

 

每个线程都有自己的工作内存，线程先把共享变量的值从主内存读到工作内存，形成一个副本，当计算完后再把副本的值刷回主内存，从读取到最后刷回主内存这是一个过程，当还没刷回主内存的时候这时候对其他线程是不可见的，所以其他线程从主内存读到的值是修改之前的旧值。

 

像CPU的缓存优化、硬件优化、指令重排及对JVM编译器的优化，都会出现可见性的问题。

 

有序性

 

我们都知道程序是按代码顺序执行的，对于单线程来说确实是如此，但在多线程情况下就不是如此了。为了优化程序执行和提高CPU的处理性能，JVM和操作系统都会对指令进行重排，也就说前面的代码并不一定都会在后面的代码前面执行，即后面的代码可能会插到前面的代码之前执行，只要不影响当前线程的执行结果。所以，指令重排只会保证当前线程执行结果一致，但指令重排后势必会影响多线程的执行结果。

 

虽然重排序优化了性能，但也是会遵守一些规则的，并不能随便乱排序，只是重排序会影响多线程执行的结果。

 

 

 

我们都知道sleep是让线程休眠，到时间后会继续执行，wait是等待，需要唤醒再继续执行，那么这两种方法在多线程中的表现形态，它们各有什么区别呢？

可以总结为以下几点。

使用上

从使用角度看，sleep是Thread线程类的方法，而wait是Object顶级类的方法。

sleep可以在任何地方使用，而wait只能在同步方法或者同步块中使用。

CPU及资源锁释放

sleep,wait调用后都会暂停当前线程并让出cpu的执行时间，但不同的是sleep不会释放当前持有的对象的锁资源，到时间后会继续执行，而wait会放弃所有锁并需要notify/notifyAll后重新获取到对象锁资源后才能继续执行。

异常捕获

sleep需要捕获或者抛出异常，而wait/notify/notifyAll不需要。

 

 

加入（）

join()是解决类Thread的方法，官方的说明是：

等待这个线程死掉。

等待这个结束，当前等待这个话题结束，然后继续执行，下面就解决了。

示例

1. public static void main(String[] args) throws Exception {

2.    System.out.println("start");

3.  

4.    Thread t = new Thread(() -> {

5.        for (int i = 0; i < 5; i++) {

6.            System.out.println(i);

7.            try {

8.                Thread.sleep(500);

9.            } catch (InterruptedException e) {

10.                e.printStackTrace();

11.            }

12.        }

13.    });

14.    t.start();

15.    t.join();

16.  

17.    System.out.println("end");

18. }

结果输出：

1. start

2. 0

3. 1

4. 2

5. 3

6. 4

7. end

t.t.join（）方法，t线程线程方法后

如果没有t.join()，结束可能会在0~5之间输出。

join()原理

下面是join()的源码：

1. public final synchronized void join(long millis)

2.    throws InterruptedException {

3.    long base = System.currentTimeMillis();

4.    long now = 0;

5.  

6.    if (millis < 0) {

7.        throw new IllegalArgumentException("timeout value is negative");

8.    }

9.  

10.    if (millis == 0) {

11.        while (isAlive()) {

12.            wait(0);

13.        }

14.    } else {

15.        while (isAlive()) {

16.            long delay = millis - now;

17.            if (delay <= 0) {

18.                break;

19.            }

20.            wait(delay);

21.            now = System.currentTimeMillis() - base;

22.        }

23.    }

24. }

就是当主要方法是通过上面的方法来实现的，主要方法是主线程处理方法的时候，主要方法是什么时候，获取到了对象的锁定，而它可以直接等待方法进行，只要当它结束或者到阻止的时候时间之后就结束了，接着主线程继续执行，等待线程一直执行。

 

 

 

我们的系统肯定有些线程为了保证业务需要是要常驻后台的，一般它们不会自己终止，需要我们通过手动来终止它们。我们知道启动一个线程是start方法，自然有一个对应的终止线程的stop方法，通过stop方法可以很快速、方便地终止一个线程，我们来看看stop的源代码。

 

 

通过注解@Deprecated看出stop方法被标为废弃的方法，jdk在以后的版本中可能被移除，不建议大家使用这种API。

 

那为什么这么好的一个方法怎么不推荐使用，还要标注为废弃呢？

 

假设有这样的一个业务场景，一个线程正在处理一个复杂的业务流程，突然间线程被调用stop而意外终止，这个业务数据还有可能是一致的吗？这样是肯定会出问题的，stop会释放锁并强制终止线程，造成执行一半的线程终止，带来的后果也是可想而知的，这就是为什么jdk不推荐使用stop终止线程的方法的原因，因为它很暴力会带来数据不一致性的问题。

 

正因为stop方法太过暴力，所以一般不推荐使用，除非你非常清楚你自己的业务场景，用stop终止不会给你的业务带来影响。

 

说了这么多，那如何优雅地终止一个线程呢？看看下面的程序。

 

 

其实也不难，只需要添加一个变量，判断这个变量在某个值的时候就退出循环，这时候每个循环为一个整合不被强行终止就不会影响单个业务的执行结果。

 

 

volatile基本介绍

 

volatile可以看成是synchronized的一种轻量级的实现，但volatile并不能完全代替synchronized，volatile有synchronized可见性的特性，但没有synchronized原子性的特性。可见性即用volatile关键字修饰的成员变量表明该变量不存在工作线程的副本，线程每次直接都从主内存中读取，每次读取的都是最新的值，这也就保证了变量对其他线程的可见性。另外，使用volatile还能确保变量不能被重排序，保证了有序性。

 

volatile只用修饰一个成员变量，如：private volatile balance;

 

volatile比synchronized编程更容易且开销更小，但具有一点的使用局限性，使用要相当小心，不能当锁使用。volatile不会像synchronized一样阻塞程序，如果是读操作远多于写操作的情况可以建议使用volatile，它会有更好的性能。

 

volatile使用场景

 

如果正确使用volatile的话，必须依赖下以下种条件：

1、对变量的写操作不依赖当前变量的值；

2、该变量没有包含在其他变量的不变式中。

 

第1个条件就说明了volatile不是原子性的操作，不能使用n++类似的计数器，它不是线程安全的。

 

1、状态的改变

 

有些场景肯定会有状态的改变，完成一个主线程的停止等。首先我们开启了一个无限循环的主线程，判断变量isStop变量是否为true，如果true的话就退出程序，否则就一直循环，所以这个isStop的值是别的线程改变的。

 

上面这段程序如果不加volatile的话会一直卡在循环，此时的线程拿到的值永远为false，加了volatile3秒后就输出stop，所以这段程序很好的解释了可见性的特点。

 

2、读多写少的情况

 

假设这样一种场景，有N个线程在读取变量的值，只有一个线程写变量的值，这时候就能保证读线程的可见性，又能保证写线程的线程安全问题。

 

像n++不是原子类的操作，其实可以通过synchronized对写方法锁住，再用volatile修饰变量，这样就保证了读线程对变量的可见性，又保证了变量的原子性。

 

 

如果n不加volatile，程序将一直循环，不能输出stop，也就是此时的线程拿到的值永远为0。当然不加volatile，对获取n的方法进行synchronized修饰也是能及时获取最新值的，但是性能会远低于volatile。

__EOF__

本文作者：夜雨闻铃
本文链接：https://www.cnblogs.com/sugeek/articles/16608508.html
关于博主：编程菜鸟一只，希望每个今天胜过昨天，一步步走向技术的高峰！
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！