java多线程

最新推荐文章于 2024-05-30 00:22:20 发布

vinojie

最新推荐文章于 2024-05-30 00:22:20 发布

阅读量116

点赞数

分类专栏： java 文章标签： java

本文链接：https://blog.csdn.net/vinojie/article/details/107447593

版权

java 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

多线程是java最基本的一种并发模型。

1、创建新线程

1.1 创建新线程的方法

方法一：从Thread派生一个自定义类，然后覆写run() 方法；线程的执行代码写在run()方法中。
方法二：创建一个Thread实例时，传入一个Runnable实例
方法三：Runnable是一个函数式接口，可以用lambda表达式简历一个实例；
在这里插入图片描述

在线程中调用Thread.sleep()，强迫线程暂停一段时间，sleep()传入的参数是毫秒。

1.2 线程的优先级

可以对线程设定优先级，设定优先级的方法是：

Thread.setPriority(int n) //1^10 默认5

优先级高的线程被操作系统调度的优先级较高，操作系统对高优先级线程可能调度更频繁，但我们决不能通过设置优先级来确保高优先级的线程一定会先执行。

2、线程的状态

在java程序中，一个线程只能调用一次start()方法启动新线程，并在新线程中执行run(）方法，一旦run(）方法执行完毕，线程就结束了。

New：新创建的线程，尚未执行；
Runnable：运行中的线程，正在执行run()方法的Java代码；
Blocked：运行中的线程，因为某些操作被阻塞而挂起；
Waiting：运行中的线程，因为某些操作在等待中； Timed
Waiting：运行中的线程，因为执行sleep()方法正在计时等待；
Terminated：线程已终止，因为run()方法执行完毕。

线程中止的原因：

线程正常终止：run()方法执行到return语句返回；
线程意外终止：run()方法因为未捕获的异常导致线程终止；
对某个线程的Thread实例调用stop()方法强制终止（强烈不推荐使用）

3、守护线程

通过调用**t.setDaemon(true)**将线程转换成守护线程，守护线程就是为其他线程提供服务，虚拟机不必等待守护线程结束才退出，当只剩下守护线程，虚拟机就推出了。守护线程应该永远不去方位固有资源，如文件、数据库，因为它会在任何时候甚至在一个操作的中间发生中断。

4、中断线程

当对一个线程调用interrupt方法时，线程的中断状态将被置位。对目标线程调用interrupt()方法可以请求中断一个线程，目标线程通过检测isInterrupted()标志获取自身是否已中断。如果目标线程处于等待状态，该线程会捕获到InterruptedException；

目标线程检测到isInterrupted()为true或者捕获了InterruptedException都应该立刻结束自身线程；

通过标志位判断需要正确使用volatile关键字；

volatile关键字解决了共享变量在线程间的可见性问题。

5、同步

5.1 关键字synchronized

当多个线程同时运行时，线程的调度由操作系统决定，程序本身无法决定，因此任何一个线程都有可能在任何指令处被操作系统暂停，然后在某个时间后继续运行。如果多个线程同时读写共享变量，会出现数据不一致的问题。

为了保持一段代码的原子性是通过加锁和解锁实现的，Java程序使用synchronized关键字对一个对象进行加锁：
synchronized保证了代码块在任意时刻最多只有一个线程能执行。

使用synchronized解决了多线程同步访问共享变量的正确性问题。但是，它的缺点是带来了性能下降。因为synchronized代码块无法并发执行。此外，加锁和解锁需要消耗一定的时间，所以，synchronized会降低程序的执行效率。

我们来概括一下如何使用synchronized：

找出修改共享变量的线程代码块；
选择一个共享实例作为锁；
使用synchronized(lockObject) { … }。

在使用synchronized的时候，不必担心抛出异常。因为无论是否有异常，都会在synchronized结束处正确释放锁；

不需要synchronized的操作
JVM规定了集中原子操作：

基本类型的赋值（long和double除外），例如：int n = m;
引用类型赋值，例如:List list = anotherList
long和double是64位数据，JVM没有明确规定64位赋值操作是不是一个原子操作，不过在x64平台的JVM是把long和double的赋值作为原子操作实现的。

5.2 wait() 和 notify()

wait和notify用于多线程协调运行：

在synchronized内部可以调用wait()使线程进入等待状态；
必须在已获得的锁对象上调用wait()方法；
在synchronized内部可以调用notify()或notifyAll()唤醒其他等待线程；
必须在已获得的锁对象上调用notify()或notifyAll()方法；
已唤醒的线程还需要重新获得锁后才能继续执行。

6、ReentrantLock

synchronized是一个很重的锁，获取必须一直等待下去，没有额外的尝试机制
java.util.concurrent.locks包提供的ReentrantLock用于替代synchronized加锁。
ReentrantLock是Java代码实现的锁，我们就必须先获取锁，然后在finally中正确释放锁,顾名思义，ReentrantLock是可重入锁，它和synchronized一样，一个线程可以多次获取同一个锁。
和synchronized不同的是，ReentrantLock可以尝试获取锁：

if (lock.tryLock(1, TimeUnit.SECONDS)) {
    try {
        ...
    } finally {
        lock.unlock();
    }
}

上述代码在尝试获取锁的时候，最多等待1秒，如果1秒后仍未获取到锁，tryLock()返回false，程序就可以做一些额外处理，而不是无限等待下去。所以，使用ReentrantLock比直接使用synchronized更安全，线程在tryLock()失败的时候不会导致死锁。

7、condition

使用ReentrantLock比直接使用synchronized更安全，可以替代synchronized进行线程同步。
用ReentranLock时可以使用Condition对象来实现wait和notify的功能。

class TaskQueue {
    private final Lock lock = new ReentrantLock();
    private final Condition condition = lock.newCondition();
    private Queue<String> queue = new LinkedList<>();

    public void addTask(String s) {
        lock.lock();
        try {
            queue.add(s);
            condition.signalAll();
        } finally {
            lock.unlock();
        }
    }

    public String getTask() {
        lock.lock();
        try {
            while (queue.isEmpty()) {
                condition.await();
            }
            return queue.remove();
        } finally {
            lock.unlock();
        }
    }
}

可见，使用Condition时，引用的Condition对象必须从Lock实例的newCondition()返回，这样才能获得一个绑定了Lock实例的Condition实例。

Condition提供的await()、signal()、signalAll()原理和synchronized锁对象的wait()、notify()、notifyAll()是一致的，并且其行为也是一样的：

8、ReadWriiteLock

使用ReadWriteLock可以提高读取效率，实现允许多个线程同时读取，但只要有一个线程在写，其他线程就必须等待。使用ReadWriteLock时，适用条件是同一个数据，有大量线程读取，但仅有少数线程修改。

9、StampedLock

ReadWriteLock有个问题：如果有个线程正在读，写线程需要等待读线程释放锁后才能获取写锁，即读的过程中不允许写，这是一种悲观的锁。要进一步提升并发执行效率，Java8引入了新的读写锁：StampedLock.

StampedLock和ReadWriteLock相比，改进之处在于：读的过程中也允许获取写锁后写入！这样一来，我们读的数据就可能不一致，所以，需要一点额外的代码来判断读的过程中是否有写入，这种读锁是一种乐观锁。

乐观锁的意思就是乐观地估计读的过程中大概率不会有写入，因此被称为乐观锁。反过来，悲观锁则是读的过程中拒绝有写入，也就是写入必须等待。显然乐观锁的并发效率更高，但一旦有小概率的写入导致读取的数据不一致，需要能检测出来，再读一遍就行.

和ReadWriteLock相比，写入的加锁是完全一样的，不同的是读取。**注意到首先我们通过tryOptimisticRead()获取一个乐观读锁，并返回版本号。接着进行读取，读取完成后，我们通过validate()去验证版本号，如果在读取过程中没有写入，版本号不变，验证成功，我们就可以放心地继续后续操作。如果在读取过程中有写入，版本号会发生变化，验证将失败。**在失败的时候，我们再通过获取悲观读锁再次读取。由于写入的概率不高，程序在绝大部分情况下可以通过乐观读锁获取数据，极少数情况下使用悲观读锁获取数据。

可见，StampedLock把读锁细分为乐观读和悲观读，能进一步提升并发效率。但这也是有代价的：一是代码更加复杂，二是StampedLock是不可重入锁，不能在一个线程中反复获取同一个锁。

StampedLock还提供了更复杂的将悲观读锁升级为写锁的功能，它主要使用在if-then-update的场景：即先读，如果读的数据满足条件，就返回，如果读的数据不满足条件，再尝试写。