线程基础、线程之间的共享和协作

约定不等于承诺〃 2022-02-22 03:02 324阅读 0赞

## 基础概念 ##

**CPU核心数和线程数的关系**  
核心数:线程数=1:1 ;使用了超线程技术后—> 1:2

**CPU时间片轮转机制**  
又称RR调度，会导致上下文切换

**什么是进程和线程**  
进程：程序运行资源分配的最小单位，进程内部有多个线程，会共享这个进程的资源  
线程：CPU调度的最小单位，必须依赖进程而存在。

**澄清并行和并发**  
并行：同一时刻，可以同时处理事情的能力  
并发：与单位时间相关，在单位时间内可以处理事情的能力

**高并发编程的意义、好处和注意事项**  
好处：充分利用cpu的资源、加快用户响应的时间，程序模块化，异步化  
问题：  
线程共享资源，存在冲突；  
容易导致死锁；  
启用太多的线程，就有搞垮机器的可能  
认识Java里的线程  
**新启线程的方式 三种**  
1. 继承Thread 类  
2. 实现userRun 实现Runable 接口  
userRun ur= new userRun （）；  
new Thread（ur）.start  
3. 实现Callable 接口， 允许有返回值. 通过FutureTask 包装  
userCall ur= new userCall （）；  
FutureTask futuretask = new FutureTask<>( ur)  
new Thread（futuretask）.start（）.  
futuretask.get() //获取返回值

java 示例

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][20190415215925808.png]  
![在这里插入图片描述][20190415215939365.png]

## 怎么样才能让Java里的线程安全停止工作呢 ##

1.  线程自然终止：自然执行完或抛出未处理异常
2.  
3.  stop()，resume(),suspend()已不建议使用。stop() ，resume()强行终止 会导致线程不会正确释放资源。suspend()挂起， 线程会占着资源进入睡眠状态， ， 其他线程拿不到此资源容易引发死锁
4.

3.java线程是协作式，而非抢占式  
调用一个线程的interrupt() 方法中断一个线程，并不是强行关闭这个线程，只是跟这个线程打个招呼，将线程的中断标志位置为true，线程是否中断，由线程本身决定。  
isInterrupted() 判定当前线程是否处于中断状态。  
static方法interrupted() 判定当前线程是否处于中断状态，同时中断标志位改为false。  
注意：方法里如果抛出InterruptedException，线程的中断标志位会被复位成false，如果确实是需要中断线程，要求我们自己在catch语句块里再次调用interrupt()。

自己理解

interrupt（）：中断一个线程。 t. interrupt（）, 并不一定会立刻终止这个线程，是否终止由t自己决定。 能够有足够的时间做自己的清理工作。 类似打个招呼， 把中断标志位置为true
    isInterrupted（）：判断当前线程是否处于中断状态。 判断中断标志位是否为true
    static  interrupted（），判断当前线程是否处于中断状态。 当调用此方法时， 会把中断标志位改为false
    
    当我们调用t. interrupt（）时， 如果没有对isInterrupted（） 进行判断并做处理， 线程是不会中断的
    
    Thread   用isInterrupted（） 判断。
    Runnable  用 Thread.currentThread().isInterrupted（）
    如果某个方法抛出interruptedException 异常之后， 会把中断标志位isInterrupted 设置为false， 则线程不会中断。 要想此线程中断， 需要在catch 里面再次调用 interrupt ， 使其中断

Thread 调用 interrupt（）示例

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 1]  
Runnable 调用 interrupt（）示例  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 2]  
抛出异常后， 需要再次调用interrupt() 方法  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 3]

## 对Java里的线程再多一点点认识 ##

**线程常用方法和线程的状态**  
线程只有5种状态。整个生命周期就是这几种状态的切换。  
新建—调用start（）方法后—》就绪（可运行状态）–通过join（）获得执行权后—》 运行状态–调用run（）/stop之后死亡

开始休眠后进入阻塞状态—》Sleep 时间到后（强行中断后）进入就绪状态  
运行等待之后也会进入阻塞状态， 通过notify（）、notifyAll 唤醒后进入就绪状态

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 4]

**run()和start()** ：run方法就是普通对象的普通方法，只有调用了start()后，Java才会将线程对象和操作系统中实际的线程进行映射，再来执行run方法

**Yield（）与sleep （）**  
让出cpu的执行权，将线程从运行转到可运行状态，但是下个时间片，该线程依然有可能被再次选中运行。调用yield时， 下个工作可做可不做， 可以吧cpu 让出来供其他使用， cpu 有可能会再次调度到  
sleep（） 方法：以为着线程进入休眠状态， cpu 不会在调度

。

## 线程的优先级 ##

**优先级**：取值为1~10，缺省为5，但线程的优先级不可靠，不建议作为线程开发时候的手段  
**守护线程**：与主线程共死的。 在线程start 之前设置 setDaemon（true）， 主线程跑完， 子线程也终止。 在守护线程里finally不能保证一定执行。

## 线程间的共享 ##

**synchronized内置锁**

多线程间变量共享，增加synchronized关键字， 可以保证我们程序有正确的行为  
确保多个线程在同一时间内只能确保只有一个线程处于方法和同步块中， 就是说当有一个线程进入到synchronized 所包围的方法中， 其他的线程必须在外面等待

1.  对象锁，锁的是类的对象实例。synchronized（this） 对象锁(new 出来的实例)  
    2.类锁 ，锁的是每个类的的Class对象，每个类的的Class对象在一个虚拟机中只有一个，所以类锁也只有一个。

Public static synchronized void synclass（） 类锁（每个类的class 对象）。锁的是静态方法、类方法  
类锁和对象锁是两个不同的锁， 即使定义到同一个类上面， 可以并发运行  
同一个类不同实例锁也是没有关联的， 可以同时进行

**volatile关键字**  
volatile 声明的变量， 在线程使用时候， 需要到内存中去获取， 而不是使用线程自己copy 的。  
但是每个线程操作完这个变量， 并不会把值写进内存。内存中这个变量的值并不会改变

只保证内存可见性， 不保证操作的原子性  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 5]  
结果：  
![在这里插入图片描述][20190415225456526.png]

加上synchronized 关键字后  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 6]

适合于只有一个线程写，多个线程读的场景，因为它只能确保可见性。（例子：定义一个valatile int a =0 , 启动4 个线程去计算a+1, 结果千奇百怪）。多用于只有一个线程写， 多个线程读的时候

**ThreadLocal**  
线程内部的局部变量，别的线程对它没有影响。 不使用synchronized 关键字，ThreadLocal 定义的变量 被许多线程调用， 仍然可以得出正确的行为：  
示例代码：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 7]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 8]

运行结果：  
![在这里插入图片描述][20190415225757253.png]  
设置一个初始值0 ，threadLocal .get 获取出事值， 进行操作完再threadLocal .set 写回去。可以理解为是个map，类型 Map<Thread,Integer>， 存储每个线程使用变量的副本， key 是线程本身， value 是变量副本。  
多个线程之前共享同一个变量， 线程之间也不会冲突。  
缺点， 占用资源可能会比较大。 每一个线程对ThreadLocal 定义的变量都有一份拷贝

## 线程间协作 ##

轮询：难以保证及时性，资源开销很大，  
等待和通知  
wait() /notify/notifyAll 对象上的方法

**等待和通知的标准范式**  
等待方：  
1、 获取对象的锁；  
2、 循环里判断条件是否满足，不满足调用wait方法，  
3、 条件满足执行业务逻辑  
通知方来说  
1、 获取对象的锁；  
2、 改变条件  
3、 通知所有等待在对象的线程

## notify和notifyAll应该用谁？ ##

线程A 和B ， 如果使用notify， 发出唤醒信号后， 如果唤醒了A ， 则B 不会在被唤醒。  
notifyAll 会唤醒所有的线程  
应该尽量使用notifyAll，使用notify因为有可能发生信号丢失的的情况  
线程被唤醒后， 还要进行判断 等待时间是否已经到了， 没有继续等待， 如果到了额， 就去执行业务逻辑  
示例：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 9]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 10]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 11]

使用notifyAll 输出以下结果：  
![在这里插入图片描述][20190409210709428.png]

使用notify（） 打印出的结果：  
![在这里插入图片描述][20190409210736506.png]

## 等待超时模式实现一个连接池 ##

假设 等待时间时长为T，当前时间now+T以后超时

long overtime = now+T;  
long remain = T;//等待的持续时间  
while(result不满足条件&& remain>0)\{  
wait(remain);  
remain = overtime – now;//等待剩下的持续时间  
\}  
return result;  
数据库超时连接  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 12]

## join()方法 ##

**面试点**  
控制下线程的工作顺序  
1.线程A，执行了线程B的join方法，线程A必须要等待B执行完成了以后，线程A才能继续自己的工作

## 调用yield() 、sleep()、wait()、notify()等方法对锁有何影响？ ##

**面试点**  
yield()：线程在执行yield()以后，虽然让出了cpu 的执行权， 但是持有的锁是不释放的  
sleep()：方法被调用以后，持有的锁是不释放的  
wait()：调动方法之前，必须要持有锁。调用了wait()方法以后，锁就会被释放，当wait方法返回的时候，线程会重新持有锁  
notify()：调动方法之前，必须要持有锁，调用notify()方法本身不会释放锁的， 代码同步块全部跑完后再释放锁， 通常将notify（） 、notifyAll （） 放到代码块的最后. b=c 执行完后才释放  
public synchronized void A（）\{  
a=b;  
notify()  
b=c  
\}

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70]: /images/20220222/2a9d75a986bd4d1182b92b51d9742b43.png
[20190415215925808.png]: /images/20220222/00084cbcd9c049e6b0874dc9f3be4acf.png
[20190415215939365.png]: /images/20220222/694ae1e763b540e2bd665fe33dcc36db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 1]: /images/20220222/c55731aba08c4530b03e550356b52f4f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 2]: /images/20220222/e94830e1edf243d790b41662ed269896.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 3]: /images/20220222/fa0365bbe15b4aaebc9fa0c1a8f408e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 4]: /images/20220222/4d61a9ce8c584aa0a44ee5a5dd01f3a3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 5]: /images/20220222/d655c52632464c34be2024e44a293bd0.png
[20190415225456526.png]: /images/20220222/76650440946c4bca93323a21422767a1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 6]: /images/20220222/833e1f7143bc4edc9b32985095185396.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 7]: /images/20220222/ede0476189614d6a8671781c13710f53.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 8]: /images/20220222/06797ec05b754cc4abede6eea3c80944.png
[20190415225757253.png]: /images/20220222/c4b974985946432597b48ecb935b3143.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 9]: /images/20220222/4ba73a907e6947648aa9966ce50ee1ec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 10]: /images/20220222/7b91fe3ead6c4702a990549e1b159738.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 11]: /images/20220222/f79560fb53e14ebdb19661812965f6f5.png
[20190409210709428.png]: /images/20220222/0d885e2c82c046a58850ffded2ad1f2f.png
[20190409210736506.png]: /images/20220222/f1ca7ef6228c4b22965ef8d72f9c87a5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNTcyNjk3_size_16_color_FFFFFF_t_70 12]: /images/20220222/09f2a5690ba947358273e66696c79bc7.png