JavaEE 5 (4/28)

1.wait() 和notify()

调用wait后做的三件事

1.释放锁

2.等待其他线程通知

3.收到通知后重新上锁,继续执行 

要想实用wait和notify就得搭配synchronized 获取锁

wait哪个对象就要针对哪个对象加锁

Java中线程是随机抢占式执行的,实际上线程的执行我们一定要有一个顺序.

join可以部分解决这个问题,但是A.join是让一个线程A挤入正在运行的线程B直到A执行完毕,才执行刚才暂停的线程B.

wait和notify都是Object类的方法

调用wait就会使线程陷入阻塞状态

直到其他线程调用notify来通知这个阻塞状态的线程,它才开始执行

2.线程的状态

3.关于多线程的案例

1.实现一个线程安全版本的单例模式

单例模式:是一个设计模式之一,设计模式就是棋谱,一些固定的代码套路

常见的设计模式就是单例模式和工厂模式

单例模式:就是一个类只能有一个实例,不能有多个,在实际开发中是很常见的

单例模式Singleton分为

饿汉模式(饿指的是着急):中午吃饭用了4个碗,吃完饭以后立即把碗给洗了(很着急)

懒汉模式:中午吃饭用了4个碗,吃完饭以后,先不洗.晚上这顿只需要两个碗,然后只洗两个即可,如果明天早上再用一个碗那么只洗一个碗   (很懒,洗的碗树=剩余没洗的-这次要用的)

                懒汉模式比较好,效率更高,不用重复洗碗了

懒汉模式线程不安全,因为多线程的时候,调用get方法的时候,方法内部有读和写的操作,不是原子性        .懒汉模式要加锁,但是不能每次进入这个方法就要加锁,因为线程不安全只可能发生在第一次的读写读操作中,一旦实例了,后面只有两个读,后面就线程安全了,但是每次进入还要有锁操作,代价比较大,所以需要优化着来写

这里解释下为什么两层if一样还要写两次,是因为他们的目的不同,第一次是为了判断是否要加锁的,第二次是为了判断是否要创建一个新的对象实例的. 并且最重要的是在多线程中加了锁以后可能会阻塞,10:00执行的加锁的前面的,可能10:30才执行到加锁的后面的,如果中间过程instance被修改了,那么就需要重新判断,如果不重新判断的话,就一定会创建个对象的实例,就达不到单例模式了

4.阻塞队列

首先

 阻塞队列用在生产者消费者模型中,用于作为他们的交易场所,减少了耦合度

这里解释一下耦合度:如果A和B的耦合度比较高,可以认为它们有直接的联系,如果修改A就要考虑B,同样如果修改B也要考虑A,并且B或者A挂了,可能会导致A或者B挂.

使用生产者消费者模型就能降低耦合

生产者消费者模型中,使用了交易场所

A只需要关注如何与队列交互,不需要关注B

B也是

 生产者消费者模型的优点

1.能够解耦合

2.能够"削峰填谷"

"削峰"就是如果请求量一下增大A的请求只是通过交易场所传给B,A不会有啥大问题,但是如果没有交易场所的话B可能处理不了大量的请求,可能会崩. 如果有交易场所,B就会保护的很好,因为阻塞满了以后不会再入队请求 

"填谷"就是如果请求量回复正常的话,交易场所(阻塞队列)中的请求还在,还会给B进行处理,B还在高速的频率处理着问题

5.指令重排序

volatile 解决了指令重排序和内存可见性问题

synchronized解决了内存可见性和原子性的问题还可以保证禁止指令重排序

6.定时器Timer

实现首先是执行任务的类(Task ),然后是Timer类

Timer类底层的数据结构是堆 PriorityQueue

自定义类型的比较要继承Comparable 接口然后重写compareto

什么时候被唤醒计算出来用wait唤醒

sleep不能中途唤醒,wait能

7.线程池

线程比进程更轻量，但是如果还是存在大量的线程，创建和销毁的代价依然不小

所以我们设计了线程池，线程创建后放到线程池中，需要用的时候从线程池去拿，用完后在放到线程池中。这样快，因为一般线程创建和销毁和使用需要牵涉到“内核态”，它具有不确定性，也就创建你的线程后可能会做其他任务，而如果放入线程池中，使用线程就是“用户态”，它比较可靠，只需完成用户指定的操作即可

一般认为“用户态”比内核态更加高效（具有可控性）