线程JUC包（二）

拼搏现实的明天。 2023-07-18 02:48 257阅读 0赞

## 获取线程的4种方式 ##

1、继承Thread类

2、实现Runnable 接口

3、实现Callable接口

4、用工具类Executors工具类或者new ThreadPoolExecute从线程池对象中获取线程

##  Lock锁与synchronized锁 ##

*  有序

Lock锁实现了线程的有序调度，而synchronized由CPU随机调度，多个线程下单，减库存，发短信的有序进行，就需要用lock来完成，

*  响应中断

那么如果这个获取锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，其他线程便只能干巴巴地等待，试想一下，这多么影响程序执行效率。因此就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间或者能够响应中断），通过Lock就可以办到。

*  释放

Lock和synchronized有一点非常大的不同，采用synchronized不需要用户去手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用；而Lock则必须要用户去手动释放锁，如果没有主动释放锁，就有可能导致出现死锁现象

## Runnable与Callable不同点 ##

1. Runnable不返回任务执行结果，Callable可返回任务执行结果

2. Callable在任务无法计算结果时抛出异常，而Runnable不能

3.Callable有泛型，Runnable没有泛型

Runnable接口：public abstract void run();

Callable接口： V call() throws Exception;

Runnable的子接口的实现类与Callable接口有关系，Runnable 的子接口 RunnableFuture<v> 的实现类FutureTask 构造器中可以传入Callable接口的实现类

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2MDQyOTM4_size_16_color_FFFFFF_t_70][]

## executor包： ##

1、总纲接口：java.util.concurrent.Executor，只有一个抽象方法void execute(Runnable command);

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2MDQyOTM4_size_16_color_FFFFFF_t_70 1][]

2、总纲接口主要子接口：java.util.concurrent.ExecutorService，有方法submit()和shutdown() submit的参数是Callable<T>或者Runnable接口，返回值用Future<T>类型接收

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2MDQyOTM4_size_16_color_FFFFFF_t_70 2][]

3、延时调度子接口：java.util.concurrent.ScheduledExecutorService 为 ExecutorService的子接口，有抽象方法：schedule()和shutdown() ，可以实现延时调用

4、线程池类：java.util.concurrent.ThreadPoolExecutor 继承了父类 java.util.concurrent.AbstractExecutorService，父类实现了ExecutorService接口，线程池中有两个执行方法：execute(没有返回值)，另一个是submit(返回一个Future<T>)，以及shutdown()

## locks包 ##

1、java.util.concurrent.locks.Lock接口：有以下方法获取锁lock()、tryLock()、tryLock(long time, TimeUnit unit)和lockInterruptibly()是用来获取锁的

lock ： 在锁上等待，直到获取锁；必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此一般来说，使用Lock必须在try\{\}catch\{\}块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生

tryLock：立即返回，获得锁返回true,没获得锁返回false；或者根据入参等待指定时间后返回，必须用try\{\}catch\{\}，在finally中释放锁，并且需要判断lock.tryLock()方法是否返回true

2、java.util.concurrent.locks.ReentrantLock：为Lock接口的实现类

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2MDQyOTM4_size_16_color_FFFFFF_t_70 3][]

3、读写锁：java.util.concurrent.locks.ReadWriteLock接口，只有连个抽象方法：Lock readLock()，Lock writeLock()

4、读写锁实现类：java.util.concurrent.locks.ReentrantReadWriteLock， 可进一步提高线程的并发性

获取锁：对象.readLock().lock()，对象.wirteLock().lock()

对于多个线程共享同一个资源的时候，多个线程同时对共享资源做读操作是不会发生线程安全性问题的，但是一旦有一个线程对共享数据做写操作其他的线程再来读写共享资源的话，就会发生数据安全性问题，所以出现了读写锁ReentrantReadWriteLock

如果有线程想申请读锁的话，首先会判断写锁是否被持有，如果写锁被持有且当前线程并不是持有写锁的线程，那么就会返回-1，获取锁失败，进入到等待队列等待。如果写锁未被线程所持有或者当前线程和持有写锁的线程是同一线程的话就会开始获取读锁

5、java.util.concurrent.locks.Condition，提供await()，singnal()与Lock锁配套使用，示例：见上图

java.util.concurrent.atomic 包中有类：Class AtomicInteger，Class AtomicLong等，定义了方法：getAndAdd，addAndGet,

确保了i++和++i的线程安全

## 静态方法锁和普通方法锁 ##

1、一个对象里面如果有多个synchronized方法，某一个时刻内，只要一个线程去调用其中的一个synchronized方法了，其它的线程都只能等待，换句话说，某一个时刻内，只能有唯一一个线程去访问这些synchronized方法，锁的是当前对象this，被锁定后，其它的线程都不能进入到当前对象的其它的synchronized方法，换成两个对象后，不是同一把锁了，情况立刻变化

2、所有的非静态同步方法用的都是同一把锁——-实例对象本身，所有的静态同步方法用的也是同一把锁——-类对象本身，

这两把锁是两个不同的对象，所以静态同步方法与非静态同步方法之间是不会有竞态条件的

## 锁的相关概念 ##

1、可重入锁：像synchronized和ReentrantLock都是可重入锁，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2

2、可中断锁：synchronized就不是可中断锁，而Lock是可中断锁，由于等待时间过长，线程不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁

3、公平锁：尽量是线程按请求顺序去执行

4、读写锁：ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2MDQyOTM4_size_16_color_FFFFFF_t_70]: /images/20230528/13200252f649400597f6408b6e4f7772.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2MDQyOTM4_size_16_color_FFFFFF_t_70 1]: /images/20230528/a8e18515e5cb41b5bb1751ee4012b4f5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2MDQyOTM4_size_16_color_FFFFFF_t_70 2]: /images/20230528/8eb4af291a9b46778c37ba3228170f38.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2MDQyOTM4_size_16_color_FFFFFF_t_70 3]: /images/20230528/29cee4bf7f7f4261a8ffef9d3c22b6a4.png