神科

JAVA架构知识总结

JAVA

通讯
- 通讯协议
- HTTP
- IO
- 计算机网络面试题
设计模式
- 七大设计原则
- 设计模式
JAVA基础加强
- 基础
- 多线程
- 登录
- 数据库
Spring
spring boot
- 和Spring区别
- springboot启动加载
spring cloud
- Ribbon：负载。
- OpenFeign：声明式伪RPC。
- Eureka
- Config
- Hystrix
- GeteWay
- Slueth 链路追踪
[spring cloud alibaba](https://blog.csdn.net/u011627218/article/details/121909029)
算法
问题
源码分析
技术点分析
- 网络
- java基础
- spring
- springboot的优势
- 数据库
- 多线程
- spring cloud

通讯

通讯协议

OSI七层

1.1、物理层：通信道上的原始比特流传输。例如网线、光纤
1.2、数据链路层：物理寻址，同时将原始比特流转变成逻辑传输线路。例如：交换机
1.3、网络层：控制子网的运行，将网路地址转换成物理地址。例如：路由器
1.4、传输层：数据包分隔。例如：TCP协议和UDP协议
1.5、会话层：不同机器上用户之间建立管理通讯。例如：LINUX和WINDOW的传输
1.6、表示层：语法的定义和关联。例如：加密、解密
1.7、应用层：各种应用程序协议。例如：HTTP、FTP

负载
2.1、四层负载：LVS、F5
2.2、七层负载：Nginx、Haproxy
TCP流量控制和拥塞控制
3.1、TCP流量控制：TCP的流量控制由滑动窗口来实现，滑动窗口控制流量取决于接收方的窗口大小。
3.2、拥塞控制：慢启动、拥塞避免、快速重传和快速恢复
TCP和UDP区别
4.1、Tcp面向连接，Udp无连接
4.2、Tcp更可靠，面向字节流；Udp快，没有拥塞控制，面向报文
4.3、Tcp保证数据正确性，和数据顺序；Udp不保证
4.4、Tcp请求头20个字节，Udp8个字节
TCP长连接和短连接区别
TCP连接三次握手和端口四次握手
排查TIME_WATI和CLOSE_WAIT：

 查看TIME_WAIT状态：netstat -an|grep TIME_WAIT
 统计：netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}'
 查看CLOSE_WAIT状态 netstat -n | awk '/^tcp/{++S[$NF]}END{for(a in s) print a,s[a]}'  导致too many open files

修改内核参数：

HTTP

简介Http
keep-alive：
2.1、http keep-alive是为了让tcp获得更久一点，在http1.0协议，以便在同一个联机上传多个http，提高socket效率
2.2、tcp keep-alive是TCP的一种检测TCP连接状态的保险机制
/proc/sys/net/ipv4/tcp_keepalive_time 闲置时间超过
/proc/sys/net/ipv4/tcp_keepalive_intvl 尝试发送侦测包
/proc/sys/net/ipv4/tcp_keepalive_probes 尝试这么多次，没有收到ack，丢弃TCP连接
2.3、nginx优化keep-alive

IO

select、poll、epoll详解
进程之间的通信方式：
2.1、管道
2.2、消息队列
2.3、共享内存
2.4、信号量
2.5、socket
IO模型
3.1、BIO -> NIO ->AIO
3.1.1、阻塞IO（BIO：
　　等待阻塞，线程交出CPU
　　socket.read()
3.1.2、非阻塞IO：
　　不等待，循环询问不交出CPU
　　whlie(true){socked.read()}
3.1.3、多路复用IO（NIO）：
　　通过selector.select()去查询每个通道是否有到达时间
　　轮询每个socket状态是在内核中进行的，非阻塞IO询问socket状态是通过用户线程去进行的
3.1.4、信号驱动IO模型：
　　用户线程发起一个IO请求操作，会给对应的socket注册一个信号函数，然后用户线程会继续执行，当内核数据就绪时会发送一个信号给用户线程，用户线程接收到信号之后，便在信号函数中调用IO读写操作来进行实际的IO请求操作。一般用UDP，TCP没用
3.1.5、异步IO模型（AIO）：
　　真正的异步IO需要操作系统更强的支持。 IO多路复用模型中，数据到达内核后通知用户线程，用户线程负责从内核空间拷贝数据; 而在异步IO模型中，当用户线程收到通知时，数据已经被操作系统从内核拷贝到用户指定的缓冲区内，用户线程直接使用即可
3.2、Netty：采用NIO
　　3.2.1、Reactor线程模型
　　　　(1)定义：一种时间驱动处理模型，类似于多路复用IO模型，包括三种角色：Reactor、Acceptor和Handler
　　　　　　①Reactor：监听事件，包括建立、读就绪、写就绪等，针对监听到的不同事件，将它们分给对应的线程处理
　　　　　　②Acceptor：处理客户端建立的连接
　　　　　　③Handler：对读写事件进行业务处理
　　　　(2)消息处理的流程
　　　　　　①Reactor：通过多路复用器监听IO事件
　　　　　　②如果建立连接事件，由Acceptor线程接受连接，并创建Handler来处理之后连接上的读写事件
　　　　　　③如果是读写事件，则Reactor会调用该连接上的handler进行业务处理
　　　　(3)三种模式
　　　　　　①单Reactor单线程模式：由一个线程来进行事件监控和时间处理
　　　　　　②单Reactor多线程模式：对于连接上的读写事件，使用线程池中的线程来进行该连接上的Handler操作，读写事件不会阻塞Reactor线程
　　　　　　③主从Reactor多线程模式：在单Reactor多线程模式的基础上，使用两个Reactor线程分别对建立连接事件和读写事件进行监听，每个Reactor线程拥有一个多路复用器。当主Reactor线程监听到连接建立事件后，创建SocketChannel，然后将SocketChannel注册到子Reactor线程的多路复用器中，使子Reactor线程监听连接的读写事件。
3.2.2、零拷贝
3.2.3、TCP粘包/拆包的原因及解决方法

3.2.4、服务端

3.2.5、客户端

3.2.6、用NIO不用AIO
　　(1)netty整体架构是reactor模型，AIO是proactor模型
　　(2)linux系统 AIO不够成熟，处理回调的结果速度更不上处理需求，供不应求，造成处理速度瓶颈，底层实现仍用Epoll，性能没有优势
　　(3)AIO预先分配缓存区，对连接数量非常大，浪费内存
　　(4)NIO中将多路请求注册在多路选择复用器上，线程轮询请求状态
　　(5)AIO每个请求一开始就分配一个线程，导致线程过多

计算机网络面试题

设计模式

七大设计原则

 开闭原则
　　一、定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。抽象约束，封装变化
　　二、优点：提高软件系统的可复用性及可维护性
 依赖倒转原则
　　一、定义：通过要面向接口的编程来降低类间的耦合性。
　　高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口编程，不要面向实现编程。
　　二、优点：
 单一职责原则
　　三、定义：不要存在多于一个导致类变更的原因。
 接口隔离原则
　　一、定义：用多个专门的接口，而不是使用单一总接口，客户端不应该依赖它不需要的接口。
 迪米特法则
　　一、定义：一个对象应该对其他对象保持最少的了解
　　二、优点：降低类之间的耦合
 里式替换原则
　　一、定义：里氏替换原则是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法
　　二、优点：
　　　　里氏替换原则是实现开闭原则的重要方式之一。
　　　　它克服了继承中重写父类造成的可复用性变差的缺点。
　　　　它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。
 合成聚合复用原则
　　一、定义：尽量使用对象组合、聚合、而不是继承关系达到软件复用的目的聚合：has-a、组合：contains-a、继承：is-a
　　二、优点：
　　　　可以使系统更加灵活，降低类与类之间的耦合度，
　　　　一个类的变化对其他类造成的影响相对较少

设计模式

 工厂模式
　　简单工厂：
　　定义：通过实例化一个工厂类，来获取对应的产品实例。我们不需要关注产品本身如何被创建的细节，只需要通过相应的工厂就可以获得相应的实例。简单工厂包括三种角色：
　　　　1.工厂：简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类的创建产品类　　的方法可以被外界直接调用，创建所需的产品对象。
　　　　2.抽象产品：简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。
　　　　3.具体产品：是简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。
优点：
 工厂方法模式
　　定义：是指定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类，工厂方法让类的实例化推迟到子类中进行。
　　优点：
　　简单工厂是产品的工厂，工厂方法是工厂的工厂
 抽象工厂模式
　　简单工厂解决的是横向的产品族，工厂方法解决的是纵向的产品等级，抽象工厂解决两者
 单例模式
一、饿汉式

缺点：某种情况浪费内存
二、懒汉式

单例模式 懒汉模式注意：
　　1）、双重校验：两个线程同时竞争锁后，当一个线程竞争到锁后初始化，另外一个线程竞争到后，又去初始化了；
　　2）、对象属性volitile定义，当一个线程初始化后，指令重排序，先给对象内存空间，另外一个线程判断不为空，返回了结果，第一个线程没有初始化后

内部静态类不是加载class后就调用，不被反射破坏（构造判断）

三、注册式单例
　　定义：将每一个实例都缓存到统一的容器中，使用唯一标识获取实例
　　reflect方法不能反射枚举
　　初始化类就构造枚举

四、ThreadLocal

五、总结
　　1、优点
　　　　(1)在内存中只有一个实例，减少了内存的开销
　　　　(2)可以避免对资源的多重占用
　　　　(3)设置全局访问点，严格控制访问

2、缺点
　　　　(1)没有接口，扩展困难
　　　　(2)如果要扩展单例对象，只有修改代码，没有其他途径
　　3、总结
　　　　(1)私有化构造器
　　　　(2)保证线程安全
　　　　(3)延迟加载
　　　　(4)防止序列化和反序列化破坏单例
　　　　(5)防御反射攻击单例

模板方法模式
　　HttpSerlet doget dopost
责任链模式
　　Tomacat filter
代理模式
　　静态代理
　　动态代理

JAVA基础加强

基础

一、Volatile与Synchronized的区别
　　（1）、volatile只能作用于变量，使用范围较小。synchronized可以用在变量、方法、类、同步代码块等，使用范围比较广。
　　（2）、volatile只能保证可见性和有序性，不能保证原子性。而可见性、有序性、原子性synchronized都可以包证。
　　（3）、volatile不会造成线程阻塞。synchronized可能会造成线程阻塞。
　　（4）、在性能方面synchronized关键字是防止多个线程同时执行一段代码，就会影响程序执行效率，而volatile关键字在某些情况下性能要优于synchronized。

多线程

 多线程基础知识
三、查看堆栈：
1、jsp：查看当前java进程的pid
2、jstack pid：查看pid对应进程的堆栈信息
四、状态（运行和就绪反了），操作系统层面没有new和terminated状态

五、Thread.start过程：调用native start0方法
java new thread start -> native start0方法 -> JVM->根据不同操作系统 -> OS ->调度算法 ->cpu
-> thread.run -> JVM -> run -> Java ->jvm销毁
六、终止线程
4.1、正常运行结束
4.2、stop：Java的API中明确了Thread.stop()方法已经被弃用了
该方法具有固有的不安全性。用 Thread.stop 来终止线程将释放它已经锁定的所有监视器（作为沿堆栈向上传播的未检查 ThreadDeath 异常的一个自然后果）。如果以前受这些监视器保护的任何对象都处于一种不一致的状态，则损坏的对象将对其他线程可见，这有可能导致任意的行为。stop 的许多使用都应由只修改某些变量以指示目标线程应该停止运行的代码来取代。目标线程应定期检查该变量，并且如果该变量指示它要停止运行，则从其运行方法依次返回。如果目标线程等待很长时间（例如基于一个条件变量），则应使用 interrupt 方法来中断该等待。

输出结果为：i=1,j=0
4.3、interrupt：设置中断标志。（此线程不一定是当前线程，而是指调用该方法的Thread实例所代表的线程），但实际上只是给线程设置一个中断标志，线程仍会继续运行。本质是通过共享变量实现线程间的通信：volitile int interrupted
七、count++
1、count=0 寄存器
2、count++
3、count=1 写入内存
八、迭代
九、dd
CAS
https://blog.csdn.net/u011506543/article/details/82392338
http://www.blogjava.net/mstar/archive/2013/04/24/398351.html
从思想上来说
Synchronized属于悲观锁，悲观地认为程序中的并发情况严重，所以严防死守。
CAS属于乐观锁，乐观地认为程序中的并发情况不那么严重，所以让线程不断去尝试更新。
缺点：
1.CPU开销较大
在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。

2.不能保证代码块的原子性
CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。比如需要保证3个变量共同进行原子性的更新，就不得不使用Synchronized了。

锁
https://mp.weixin.qq.com/s/9gt1rj5y1V8u_Ge4rVVY4A

Lock
1、ReentrantLock:（轻量级锁）也可以叫对象锁，可重入锁，互斥锁。synchronized重量级锁，JDK前期的版本lock比synchronized更快，在JDK1.5之后synchronized引入了偏向锁，轻量级锁和重量级锁。以致两种锁性能旗鼓相当，看个人喜欢
LOCK.lock(): 此方式会始终处于等待中，即使调用B.interrupt()也不能中断，除非线程A调用LOCK.unlock()释放锁。
LOCK.lockInterruptibly(): 此方式会等待，但当调用B.interrupt()会被中断等待，并抛出InterruptedException异常，否则会与lock()一样始终处于等待中，直到线程A释放锁。
LOCK.tryLock(): 该处不会等待，获取不到锁并直接返回false，去执行下面的逻辑。
LOCK.tryLock(10, TimeUnit.SECONDS)：该处会在10秒时间内处于等待中，但当调用B.interrupt()会被中断等待，并抛出InterruptedException。10秒时间内如果线程A释放锁，会获取到锁并返回true，否则10秒过后会获取不到锁并返回false，去执行下面的逻辑
lock和tryLock的区别:
1: lock拿不到锁会一直等待。tryLock是去尝试，拿不到就返回false，拿到返回true。
2: tryLock是可以被打断的，被中断的，lock是不可以。
源码分析：
1.1、构造函数：是否公平锁 true-公平锁，false-非公平锁（默认）

1.2、非公平锁
如果获取到锁，继续（保证吞吐量）
如果没有获取到锁的线程，添加到AQS队列尾部：如果AQS只有当前线程节点，不挂起；否则移除当前线程节点前CACELLED节点，修改其他节点state=SIGNAL，当前线程节点挂起

（1）、cas 乐观锁获取锁并修改：state=0->1,exclusiveOwnerThread =thread；CAS：只允许一个线程进入
（2）、如果有多线程cas 失败，等待线程构造线程节点到AQS队列中：acquire方法

1.2.1、tryAcquire：如果抢占到锁或者重入锁，继续跳出判断acquireQueue
1.2.2、addWaiter(Node.EXCLUSIVE), arg)创建等待线程节点

首次轮询进入enq（node）：当前AQS队列没有节点，创建空节点，并指向当前线程节点（双向链表）

1.2.3、acquireQueued：如果AQS只有当前线程节点，不挂起；否则移除当前线程节点去前CACELLED节点，修改其他节点state=SIGNAL，当前线程节点 LockSupport.park(this)阻塞挂起，并自旋直到抢占到锁

1.2.4、如果自旋抢占到锁，1：设置head节点next=null，2：设置当前线程节点为head节点，并设置node.thread=null，node.prev=null

1.2.5、 selfInterrupt:lock获取锁过程中，忽略了中断(即1.2.3、acquireQueued 挂起当前节点时)，在成功获取锁之后，再根据中断标识处理中断，即selfInterrupt中断自己，往上传递
1.2.5、unlock：1：释放锁。修改state状态为0，exclusiveOwnerThread =null；2：唤醒AQS消息队列的watstatus =SINGNAL节点

1.2.4.1：释放锁。修改state状态为0，exclusiveOwnerThread =null

1.2.4.2：唤醒AQS消息队列的watstatus =SINGNAL节点

1.3、公平锁

1.4、公平锁和非公平锁区别
1.4.1、lock获取锁。公平锁：AQS没有等待队列才CAS抢占，非公平锁：第一步先CAS抢占，抢占不到在添加到AQS队列尾节点

2、ReentrantReadWriteLock：(可重入读写锁) 需要分析源码 https://www.cnblogs.com/xiaoxi/p/9140541.html
(1)可重入：同一个线程可以重复加锁，每次加锁的时候count值加1，每次释放锁的时候count减1，直到count为0，其他的线程才可以再次获取
(2)读写分离：读写两把不同的锁
(3)读锁可重复获取
1)读锁

2)写锁

(4)可以锁降级（使用逻辑）：线程获取写入锁后可以获取读取锁，然后释放写入锁，这样就从写入锁变成了读取锁，从而实现锁降级的特性

(5)不可锁升级（使用逻辑）：线程获取读锁是不能直接升级为写入锁的。需要释放所有读取锁，才可获取写

synchronized
一、锁的范围
对象实例锁：实例
类锁：静态方法、类对象
代码块锁：方法

二、锁的存储

2.1、对象头

2.2、打印出来
pom引用
org.openjdk.jol
jol-core
0.10
代码：
System.out.println(ClassLayout.parseInstance(classLayoutDemo).toPrintable())

2.3、缺点，如果锁内容中用到类似hashcode膨胀至重量级锁
三、锁的升级
3.1、偏向锁
在大多数情况下，锁不仅仅不存在多线程的竞争，而且总是由同一个线程多次获得。在这个背景下就设
计了偏向锁。偏向锁，顾名思义，就是锁偏向于某个线程。
当一个线程访问加了同步锁的代码块时，会在对象头中存储当前线程的ID，后续这个线程进入和退出这
段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接比较对象头里面是否存储了指向当前线
程的偏向锁。如果相等表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，引入偏向锁是为了
在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径。（偏向锁的目的是消除数据在无竞争情
况下的同步原语，进一步提高程序的运行性能。）

3.2、轻量级锁
如果偏向锁被关闭或者当前偏向锁已经已经被其他线程获取，那么这个时候如果有线程去抢占同步锁时，锁会升级到轻量级锁。
3.3、重量级锁
多个线程竞争同一个锁的时候，虚拟机会阻塞加锁失败的线程，并且在目标锁被释放的时候，唤醒这些线程；
Java 线程的阻塞以及唤醒，都是依靠操作系统来完成的：os pthread_mutex_lock() ；
升级为重量级锁时，锁标志的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态

每一个JAVA对象都会与一个监视器monitor关联，我们可以把它理解成为一把锁，当一个线程想要执行一段被synchronized修饰的同步方法或者代码块时，该线程得先获取到synchronized修饰的对象对应的monitor。
monitorenter表示去获得一个对象监视器。monitorexit表示释放monitor监视器的所有权，使得其他被阻塞的线程可以尝试去获得这个监视器
monitor依赖操作系统的MutexLock(互斥锁)来实现的,线程被阻塞后便进入内核（Linux）调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响锁的性能

任意线程对Object（Object由synchronized保护）的访问，首先要获得Object的监视器。如果获取失败，线程进入同步队列，线程状态变为BLOCKED。当访问Object的前驱（获得了锁的线程）释放了锁，则该释放操作唤醒阻塞在同步队列中的线程，使其重新尝试对监视器的获取。
3.4、总结
偏向锁只有在第一次请求时采用CAS在锁对象的标记中记录当前线程的地址，在之后该线程再次进入同步代码块时，不需要抢占锁，直接判断线程ID即可，这种适用于锁会被同一个线程多次抢占的情况。
轻量级锁才用CAS操作，把锁对象的标记字段替换为一个指针指向当前线程栈帧中的LockRecord，该工件存储锁对象原本的标记字段，它针对的是多个线程在不同时间段内申请通一把锁的情况。
重量级锁会阻塞、和唤醒加锁的线程，它适用于多个线程同时竞争同一把锁的情况。

wait、notify、notifyall
https://www.jianshu.com/p/25e243850bd2?appinstall=0

1、多线程wait 和 notify的判断条件用while，不用if（假死）
(1)if(){…}，如果说程序在判断完满足if条件之后，那么就会进入大括号里面，即使在里面等待一段时间之后，我们也是会直接出来。
(2)while(){…}如果说满足了条件，那么就会进入大括号里面，在里面呆了一段时间，要想出来那得先去while判断一下，如果满足，还是不能出来。
2、结尾处的为什么要用notifyAll()方法，不用notify()

其实这是一个对象内部锁的调度问题，要回答这两个问题，首先我们要明白java中对象锁的模型，JVM会为一个使用内部锁（synchronized）的对象维护两个集合，Entry Set和Wait Set，也有人翻译为锁池和等待池，意思基本一致。

对于Entry Set：如果线程A已经持有了对象锁，此时如果有其他线程也想获得该对象锁的话，它只能进入Entry Set，并且处于线程的BLOCKED状态。

对于Wait Set：如果线程A调用了wait()方法，那么线程A会释放该对象的锁，进入到Wait Set，并且处于线程的WAITING状态。

还有需要注意的是，某个线程B想要获得对象锁，一般情况下有两个先决条件，一是对象锁已经被释放了（如曾经持有锁的前任线程A执行完了synchronized代码块或者调用了wait()方法等等），二是线程B已处于RUNNABLE状态。

那么这两类集合中的线程都是在什么条件下可以转变为RUNNABLE呢？

对于Entry Set中的线程，当对象锁被释放的时候，JVM会唤醒处于Entry Set中的某一个线程，这个线程的状态就从BLOCKED转变为RUNNABLE。

对于Wait Set中的线程，当对象的notify()方法被调用时，JVM会唤醒处于Wait Set中的某一个线程，这个线程的状态就从WAITING转变为RUNNABLE；或者当notifyAll()方法被调用时，Wait Set中的全部线程会转变为RUNNABLE状态。所有Wait Set中被唤醒的线程会被转移到Entry Set中。

然后，每当对象的锁被释放后，那些所有处于RUNNABLE状态的线程会共同去竞争获取对象的锁，最终会有一个线程（具体哪一个取决于JVM实现，队列里的第一个？随机的一个？）真正获取到对象的锁，而其他竞争失败的线程继续在Entry Set中等待下一次机会。

耐心看下面这个两个生产者两个消费者的场景，如果我们代码中使用了notify()而非notifyAll()，假设消费者线程1拿到了锁，判断buffer为空，那么wait()，释放锁；然后消费者2拿到了锁，同样buffer为空，wait()，也就是说此时Wait Set中有两个线程；然后生产者1拿到锁，生产，buffer满，notify()了，那么可能消费者1被唤醒了，但是此时还有另一个线程生产者2在Entry Set中盼望着锁，并且最终抢占到了锁，但因为此时buffer是满的，因此它要wait()；然后消费者1拿到了锁，消费，notify()；这时就有问题了，此时生产者2和消费者2都在Wait Set中，buffer为空，如果唤醒生产者2，没毛病；但如果唤醒了消费者2，因为buffer为空，它会再次wait()，这就尴尬了，万一生产者1已经退出不再生产了，没有其他线程在竞争锁了，只有生产者2和消费者2在Wait Set中互相等待，那传说中的死锁就发生了。

但如果你把上述例子中的notify()换成notifyAll()，这样的情况就不会再出现了，因为每次notifyAll()都会使其他等待的线程从Wait Set进入Entry Set，从而有机会获得锁。

其实说了这么多，一句话解释就是之所以我们应该尽量使用notifyAll()的原因就是，notify()非常容易导致死锁。当然notifyAll并不一定都是优点，毕竟一次性将Wait Set中的线程都唤醒是一笔不菲的开销，如果你能handle你的线程调度，那么使用notify()也是有好处的。

volatile
一、思考

jrt优化成:
if(stop){
while(true){
i++;
}
}
阻止jrt优化：
1、系统参数：-Djava.compiler = NONE
2、synchronized:sout、syschronized()
3、IO:new File(“”)
4、官方说自由加载stop值，Thread.sleep(0)会导致线程切换，资源重新竞争
https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.3
在这段代码中，我们增加Thread.sleep(0)也能生效，这个我认为是和cpu、以及jvm、操作系统等因素有关系。
官方文档上是说，Thread.sleep没有任何同步语义，编译器不需要在调用Thread.sleep之前把缓存在寄存器中的写刷新到给共享内存、也不需要在Thread.sleep之后重新加载缓存在寄存器中的值。编译器可以自由选择读取stop的值一次或者多次，这个是由编译器自己来决定的。
但是在Mic老师认为：Thread.sleep(0)导致线程切换，线程切换会导致缓存失效从而读取到了新的值。
5、volitile定义i变量或者stop变量
二、汇报指令
使用volatile关键字之后，多了一个Lock指令
三、总线锁和缓存锁
1、总线锁
总线锁，简单来说就是，在多cpu下，当其中一个处理器要对共享内存进行操作的时候，在总线上发出一个LOCK#信号，这个信号使得其他处理器无法通过总线来访问到共享内存中的数据，总线锁定把CPU和内存之间的通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，所以总线锁定的开销比较大，这种机制显然是不合适的。
如何优化呢？最好的方法就是控制锁的保护粒度，我们只需要保证对于被多个CPU缓存的同一份数据是一致的就行。在P6架构的CPU后，引入了缓存锁，如果当前数据已经被CPU缓存了，并且是要协会到主内存中的，就可以采用缓存锁来解决问题。
2、缓存锁
所谓的缓存锁，就是指内存区域如果被缓存在处理器的缓存行中，并且在Lock期间被锁定，那么当它执行锁操作回写到内存时，不再总线上加锁，而是修改内部的内存地址，基于缓存一致性协议来保证操作的原子性。
3、注意：总线锁和缓存锁怎么选择，取决于很多因素，比如CPU是否支持、以及存在无法缓存的数据时（比较大或者快约多个缓存行的数据），必然还是会使用总线锁。
四、缓存一致性
为了达到数据访问的一致，需要各个处理器在访问缓存时遵循一些协议，在读写时根据协议来操作，常见的协议有MSI，MESI，MOSI等。最常见的就是MESI协议。
MESI表示缓存行的四种状态，分别是

M(Modify) 表示共享数据只缓存在当前CPU缓存中，并且是被修改状态，也就是缓存的数据和主内存中的数据不一致
E(Exclusive) 表示缓存的独占状态，数据只缓存在当前CPU缓存中，并且没有被修改
S(Shared) 表示数据可能被多个CPU缓存，并且各个缓存中的数据和主内存数据一致
I(Invalid) 表示缓存已经失效
五、MESI优化 stiore bufferes
Store Bufferes是一个写的缓冲，对于上述描述的情况，CPU0可以先把写入的操作先存储到StoreBufferes中，Store Bufferes中的指令再按照缓存一致性协议去发起其他CPU缓存行的失效。而同步来说CPU0可以不用等到Acknowledgement，继续往下执行其他指令，直到收到CPU0收到Acknowledgement再更新到缓存，再从缓存同步到主内存。
六、MESI优化引发指令重排序
七、不能保证原子性，两个线程i++
八、应用：单例 double判空

hashmap
https://blog.csdn.net/woshimaxiao1/article/details/83661464
一、什么是哈希表
在讨论哈希表之前，我们先大概了解下其他数据结构在新增，查找等基础操作执行性能
数组：采用一段连续的存储单元来存储数据。对于指定下标的查找，时间复杂度为O(1)；通过给定值进行查找，需要遍历数组，逐一比对给定关键字和数组元素，时间复杂度为O(n)，当然，对于有序数组，则可采用二分查找，插值查找，斐波那契查找等方式，可将查找复杂度提高为O(logn)；对于一般的插入删除操作，涉及到数组元素的移动，其平均复杂度也为O(n)
线性链表：对于链表的新增，删除等操作（在找到指定操作位置后），仅需处理结点间的引用即可，时间复杂度为O(1)，而查找操作需要遍历链表逐一进行比对，复杂度为O(n)
二叉树：对一棵相对平衡的有序二叉树，对其进行插入，查找，删除等操作，平均复杂度均为O(logn)。
哈希表：相比上述几种数据结构，在哈希表中进行添加，删除，查找等操作，性能十分之高，不考虑哈希冲突的情况下（后面会探讨下哈希冲突的情况），仅需一次定位即可完成，时间复杂度为O(1)，接下来我们就来看看哈希表是如何实现达到惊艳的常数阶O(1)的。
我们知道，数据结构的物理存储结构只有两种：顺序存储结构和链式存储结构（像栈，队列，树，图等是从逻辑结构去抽象的，映射到内存中，也这两种物理组织形式），而在上面我们提到过，在数组中根据下标查找某个元素，一次定位就可以达到，哈希表利用了这种特性，哈希表的主干就是数组。
比如我们要新增或查找某个元素，我们通过把当前元素的关键字通过某个函数映射到数组中的某个位置，通过数组下标一次定位就可完成操作。
　　
这个函数可以简单描述为：存储位置 = f(关键字) ，这个函数f一般称为哈希函数，这个函数的设计好坏会直接影响到哈希表的优劣。举个例子，比如我们要在哈希表中执行插入操作：
插入过程如下图所示

查找操作同理，先通过哈希函数计算出实际存储地址，然后从数组中对应地址取出即可。
哈希冲突
然而万事无完美，如果两个不同的元素，通过哈希函数得出的实际存储地址相同怎么办？也就是说，当我们对某个元素进行哈希运算，得到一个存储地址，然后要进行插入的时候，发现已经被其他元素占用了，其实这就是所谓的哈希冲突，也叫哈希碰撞。前面我们提到过，哈希函数的设计至关重要，好的哈希函数会尽可能地保证计算简单和散列地址分布均匀,但是，我们需要清楚的是，数组是一块连续的固定长度的内存空间，再好的哈希函数也不能保证得到的存储地址绝对不发生冲突。那么哈希冲突如何解决呢？哈希冲突的解决方案有多种:开放定址法（发生冲突，继续寻找下一块未被占用的存储地址），再散列函数法，链地址法，而HashMap即是采用了链地址法，也就是数组+链表的方式。
二、HashMap的实现原理
HashMap的主干是一个Entry数组。Entry是HashMap的基本组成单元，每一个Entry包含一个key-value键值对。（其实所谓Map其实就是保存了两个对象之间的映射关系的一种集合）
//HashMap的主干数组，可以看到就是一个Entry数组，初始值为空数组{}，主干数组的长度一定是2的次幂。//至于为什么这么做，后面会有详细分析。transient Entry[] table = (Entry[]) EMPTY_TABLE;
1
2
3
Entry是HashMap中的一个静态内部类。代码如下
static class Entry implements Map.Entry {
final K key;
V value;
Entry next;//存储指向下一个Entry的引用，单链表结构
int hash;//对key的hashcode值进行hash运算后得到的值，存储在Entry，避免重复计算

    /**
     * Creates new entry.
     */
    Entry(int h, K k, V v, Entry n) {
        value = v;
        next = n;
        key = k;
        hash = h;
    }

所以，HashMap的总体结构如下：

简单来说，HashMap由数组+链表组成的，数组是HashMap的主体，链表则是主要为了解决哈希冲突而存在的，如果定位到的数组位置不含链表（当前entry的next指向null）,那么查找，添加等操作很快，仅需一次寻址即可；如果定位到的数组包含链表，对于添加操作，其时间复杂度为O(n)，首先遍历链表，存在即覆盖，否则新增；对于查找操作来讲，仍需遍历链表，然后通过key对象的equals方法逐一比对查找。所以，性能考虑，HashMap中的链表出现越少，性能才会越好。
其他几个重要字段
/*实际存储的key-value键值对的个数/transient int size;
/**阈值，当table == {}时，该值为初始容量（初始容量默认为16）；当table被填充了，也就是为table分配内存空间后，
threshold一般为 capacityloadFactory。HashMap在进行扩容时需要参考threshold，后面会详细谈到/int threshold;
/**负载因子，代表了table的填充度有多少，默认是0.75
加载因子存在的原因，还是因为减缓哈希冲突，如果初始桶为16，等到满16个元素才扩容，某些桶里可能就有不止一个元素了。
所以加载因子默认为0.75，也就是说大小为16的HashMap，到了第13个元素，就会扩容成32。
*/final float loadFactor;
/*HashMap被改变的次数，由于HashMap非线程安全，在对HashMap进行迭代时，
如果期间其他线程的参与导致HashMap的结构发生变化了（比如put，remove等操作），
需要抛出异常ConcurrentModificationException/transient int modCount;
HashMap有4个构造器，其他构造器如果用户没有传入initialCapacity 和loadFactor这两个参数，会使用默认值
initialCapacity默认为16，loadFactory默认为0.75
我们看下其中一个
public HashMap(int initialCapacity, float loadFactor) {
　　　　　//此处对传入的初始容量进行校验，最大不能超过MAXIMUM_CAPACITY = 1<<30(230)
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " +
initialCapacity);
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: " +
loadFactor);

    this.loadFactor = loadFactor;
    threshold = initialCapacity;

init();//init方法在HashMap中没有实际实现，不过在其子类如 linkedHashMap中就会有对应实现
}
从上面这段代码我们可以看出，在常规构造器中，没有为数组table分配内存空间（有一个入参为指定Map的构造器例外），而是在执行put操作的时候才真正构建table数组
OK,接下来我们来看看put操作的实现
public V put(K key, V value) {
//如果table数组为空数组{}，进行数组填充（为table分配实际内存空间），入参为threshold，
//此时threshold为initialCapacity 默认是1<<4(24=16)
if (table == EMPTY_TABLE) {
inflateTable(threshold);
}
//如果key为null，存储位置为table[0]或table[0]的冲突链上
if (key == null)
return putForNullKey(value);
int hash = hash(key);//对key的hashcode进一步计算，确保散列均匀
int i = indexFor(hash, table.length);//获取在table中的实际位置
for (Entry e = table[i]; e != null; e = e.next) {
//如果该对应数据已存在，执行覆盖操作。用新value替换旧value，并返回旧value
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(this);
return oldValue;
}
}
modCount++;//保证并发访问时，若HashMap内部结构发生变化，快速响应失败
addEntry(hash, key, value, i);//新增一个entry
return null;
}
inflateTable这个方法用于为主干数组table在内存中分配存储空间，通过roundUpToPowerOf2(toSize)可以确保capacity为大于或等于toSize的最接近toSize的二次幂，比如toSize=13,则capacity=16;to_size=16,capacity=16;to_size=17,capacity=32.
private void inflateTable(int toSize) {
int capacity = roundUpToPowerOf2(toSize);//capacity一定是2的次幂
/**此处为threshold赋值，取capacity*loadFactor和MAXIMUM_CAPACITY+1的最小值，
capaticy一定不会超过MAXIMUM_CAPACITY，除非loadFactor大于1 */
threshold = (int) Math.min(capacity * loadFactor, MAXIMUM_CAPACITY + 1);
table = new Entry[capacity];
initHashSeedAsNeeded(capacity);
}
roundUpToPowerOf2中的这段处理使得数组长度一定为2的次幂，Integer.highestOneBit是用来获取最左边的bit（其他bit位为0）所代表的数值.
private static int roundUpToPowerOf2(int number) {
// assert number >= 0 : “number must be non-negative”;
return number >= MAXIMUM_CAPACITY
? MAXIMUM_CAPACITY
: (number > 1) ? Integer.highestOneBit((number - 1) << 1) : 1;
}

hash函数
/*这是一个神奇的函数，用了很多的异或，移位等运算
对key的hashcode进一步进行计算以及二进制位的调整等来保证最终获取的存储位置尽量分布均匀/final int hash(Object k) {
int h = hashSeed;
if (0 != h && k instanceof String) {
return sun.misc.Hashing.stringHash32((String) k);
}

    h ^= k.hashCode();

    h ^= (h >>> 20) ^ (h >>> 12);
    return h ^ (h >>> 7) ^ (h >>> 4);
}

以上hash函数计算出的值，通过indexFor进一步处理来获取实际的存储位置
/**
* 返回数组下标
*/
static int indexFor(int h, int length) {
return h & (length-1);
}
h&（length-1）保证获取的index一定在数组范围内，举个例子，默认容量16，length-1=15，h=18,转换成二进制计算为index=2。位运算对计算机来说，性能更高一些（HashMap中有大量位运算）
所以最终存储位置的确定流程是这样的：

再来看看addEntry的实现：
void addEntry(int hash, K key, V value, int bucketIndex) {
if ((size >= threshold) && (null != table[bucketIndex])) {
resize(2 * table.length);//当size超过临界阈值threshold，并且即将发生哈希冲突时进行扩容
hash = (null != key) ? hash(key) : 0;
bucketIndex = indexFor(hash, table.length);
}

    createEntry(hash, key, value, bucketIndex);
}

通过以上代码能够得知，当发生哈希冲突并且size大于阈值的时候，需要进行数组扩容，扩容时，需要新建一个长度为之前数组2倍的新的数组，然后将当前的Entry数组中的元素全部传输过去，扩容后的新数组长度为之前的2倍，所以扩容相对来说是个耗资源的操作。
三、为何HashMap的数组长度一定是2的次幂？
我们来继续看上面提到的resize方法
void resize(int newCapacity) {
Entry[] oldTable = table;
int oldCapacity = oldTable.length;
if (oldCapacity == MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return;
}

    Entry[] newTable = new Entry[newCapacity];
    transfer(newTable, initHashSeedAsNeeded(newCapacity));
    table = newTable;
    threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
}

如果数组进行扩容，数组长度发生变化，而存储位置 index = h&(length-1),index也可能会发生变化，需要重新计算index，我们先来看看transfer这个方法
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
　　　　　//for循环中的代码，逐个遍历链表，重新计算索引位置，将老数组数据复制到新数组中去（数组不存储实际数据，所以仅仅是拷贝引用而已）
for (Entry e : table) {
while(null != e) {
Entry next = e.next;
if (rehash) {
e.hash = null == e.key ? 0 : hash(e.key);
}
int i = indexFor(e.hash, newCapacity);
//将当前entry的next链指向新的索引位置,newTable[i]有可能为空，有可能也是个entry链，如果是entry链，直接在链表头部插入。
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}
这个方法将老数组中的数据逐个链表地遍历，扔到新的扩容后的数组中，我们的数组索引位置的计算是通过对key值的hashcode进行hash扰乱运算后，再通过和 length-1进行位运算得到最终数组索引位置。
HashMap的数组长度一定保持2的次幂，比如16的二进制表示为 10000，那么length-1就是15，二进制为01111，同理扩容后的数组长度为32，二进制表示为100000，length-1为31，二进制表示为011111。从下图可以我们也能看到这样会保证低位全为1，而扩容后只有一位差异，也就是多出了最左位的1，这样在通过 h&(length-1)的时候，只要h对应的最左边的那一个差异位为0，就能保证得到的新的数组索引和老数组索引一致(大大减少了之前已经散列良好的老数组的数据位置重新调换)，个人理解。

还有，数组长度保持2的次幂，length-1的低位都为1，会使得获得的数组索引index更加均匀

我们看到，上面的&运算，高位是不会对结果产生影响的（hash函数采用各种位运算可能也是为了使得低位更加散列），我们只关注低位bit，如果低位全部为1，那么对于h低位部分来说，任何一位的变化都会对结果产生影响，也就是说，要得到index=21这个存储位置，h的低位只有这一种组合。这也是数组长度设计为必须为2的次幂的原因。

如果不是2的次幂，也就是低位不是全为1此时，要使得index=21，h的低位部分不再具有唯一性了，哈希冲突的几率会变的更大，同时，index对应的这个bit位无论如何不会等于1了，而对应的那些数组位置也就被白白浪费了。
get方法：
public V get(Object key) {
　　　　 //如果key为null,则直接去table[0]处去检索即可。
if (key == null)
return getForNullKey();
Entry entry = getEntry(key);
return null == entry ? null : entry.getValue();
 }
get方法通过key值返回对应value，如果key为null，直接去table[0]处检索。我们再看一下getEntry这个方法
final Entry getEntry(Object key) {

    if (size == 0) {
        return null;
    }
    //通过key的hashcode值计算hash值
    int hash = (key == null) ? 0 : hash(key);
    //indexFor (hash&length-1) 获取最终数组索引，然后遍历链表，通过equals方法比对找出对应记录
    for (Entry e = table[indexFor(hash, table.length)];
         e != null;
         e = e.next) {
        Object k;
        if (e.hash == hash && 
            ((k = e.key) == key || (key != null && key.equals(k))))
            return e;
    }
    return null;

}
可以看出，get方法的实现相对简单，key(hashcode)–>hash–>indexFor–>最终索引位置，找到对应位置table[i]，再查看是否有链表，遍历链表，通过key的equals方法比对查找对应的记录。要注意的是，有人觉得上面在定位到数组位置之后然后遍历链表的时候，e.hash == hash这个判断没必要，仅通过equals判断就可以。其实不然，试想一下，如果传入的key对象重写了equals方法却没有重写hashCode，而恰巧此对象定位到这个数组位置，如果仅仅用equals判断可能是相等的，但其hashCode和当前对象不一致，这种情况，根据Object的hashCode的约定，不能返回当前对象，而应该返回null，后面的例子会做出进一步解释。
四、重写equals方法需同时重写hashCode方法
最后我们再聊聊老生常谈的一个问题，各种资料上都会提到，“重写equals时也要同时覆盖hashcode”，我们举个小例子来看看，如果重写了equals而不重写hashcode会发生什么样的问题
public class MyTest {
private static class Person{
int idCard;
String name;

    public Person(int idCard, String name) {
        this.idCard = idCard;
        this.name = name;
    }
    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (o == null || getClass() != o.getClass()){
            return false;
        }
        Person person = (Person) o;
        //两个对象是否等值，通过idCard来确定
        return this.idCard == person.idCard;
    }

}
public static void main(String []args){
    HashMap map = new HashMap();
    Person person = new Person(1234,"乔峰");
    //put到hashmap中去
    map.put(person,"天龙八部");
    //get取出，从逻辑上讲应该能输出“天龙八部”
    System.out.println("结果:"+map.get(new Person(1234,"萧峰")));
}}

实际输出结果：null5
如果我们已经对HashMap的原理有了一定了解，这个结果就不难理解了。尽管我们在进行get和put操作的时候，使用的key从逻辑上讲是等值的（通过equals比较是相等的），但由于没有重写hashCode方法，所以put操作时，key(hashcode1)–>hash–>indexFor–>最终索引位置，而通过key取出value的时候 key(hashcode1)–>hash–>indexFor–>最终索引位置，由于hashcode1不等于hashcode2，导致没有定位到一个数组位置而返回逻辑上错误的值null（也有可能碰巧定位到一个数组位置，但是也会判断其entry的hash值是否相等，上面get方法中有提到。）
所以，在重写equals的方法的时候，必须注意重写hashCode方法，同时还要保证通过equals判断相等的两个对象，调用hashCode方法要返回同样的整数值。而如果equals判断不相等的两个对象，其hashCode可以相同（只不过会发生哈希冲突，应尽量避免）。
五、JDK1.8中HashMap的性能优化
假如一个数组槽位上链上数据过多（即拉链过长的情况）导致性能下降该怎么办？
JDK1.8在JDK1.7的基础上针对增加了红黑树来进行优化。即当链表超过8时，链表就转换为红黑树，利用红黑树快速增删改查的特点提高HashMap的性能，其中会用到红黑树的插入、删除、查找等算法。
关于这方面的探讨我们以后的文章再做说明。
附：HashMap put方法逻辑图（JDK1.8）

数组长度保持2的次幂原因：
1、扩容h最左边差异0-1，保证得到的新数组索引和老数组索引一致，大大减少了之前已经散列的老数组部分位置重新调换
2、length-1的低位都为1，会使得数组的索引更加均匀
 Condition
在使用Lock之前，我们使用的最多的同步方式应该是synchronized关键字来实现同步方式了。配合Object的wait()、notify()系列方法可以实现等待/通知模式。Condition接口也提供了类似Object的监视器方法，与Lock配合可以实现等待/通知模式，但是这两者在使用方式以及功能特性上还是有差别的。Object和Condition接口的一些对比。摘自《Java并发编程的艺术》

一、Condition接口介绍和示例
首先我们需要明白condition对象是依赖于lock对象的，意思就是说condition对象需要通过lock对象进行创建出来(调用Lock对象的newCondition()方法)。consition的使用方式非常的简单。但是需要注意在调用方法前获取锁。
public class ConditionUseCase {
public Lock lock = new ReentrantLock();
public Condition condition = lock.newCondition();
public static void main(String[] args) {
ConditionUseCase useCase = new ConditionUseCase();
ExecutorService executorService = Executors.newFixedThreadPool (2);
executorService.execute(new Runnable() {
@Override
public void run() {
useCase.conditionWait();
}
});
executorService.execute(new Runnable() {
@Override
public void run() {
useCase.conditionSignal();
}
});
}

public void conditionWait()  {
    lock.lock();
    try {
        System.out.println(Thread.currentThread().getName() + "拿到锁了");
        System.out.println(Thread.currentThread().getName() + "等待信号");
        condition.await();
        System.out.println(Thread.currentThread().getName() + "拿到信号");
    }catch (Exception e){
    }finally {
        lock.unlock();
    }
}
public void conditionSignal() {
    lock.lock();
    try {
        Thread.sleep(5000);
        System.out.println(Thread.currentThread().getName() + "拿到锁了");
        condition.signal();
        System.out.println(Thread.currentThread().getName() + "发出信号");
    }catch (Exception e){
    }finally {
        lock.unlock();
    }
}

}

输出结果：
1 pool-1-thread-1拿到锁了
2 pool-1-thread-1等待信号
3 pool-1-thread-2拿到锁了
4 pool-1-thread-2发出信号
5 pool-1-thread-1拿到信号
如示例所示，一般都会将Condition对象作为成员变量。当调用await()方法后，当前线程会释放锁并在此等待，而其他线程调用Condition对象的signal()方法，通知当前线程后，当前线程才从await()方法返回，并且在返回前已经获取了锁。
二、Condition接口常用方法
condition可以通俗的理解为条件队列。当一个线程在调用了await方法以后，直到线程等待的某个条件为真的时候才会被唤醒。这种方式为线程提供了更加简单的等待/通知模式。Condition必须要配合锁一起使用，因为对共享状态变量的访问发生在多线程环境下。一个Condition的实例必须与一个Lock绑定，因此Condition一般都是作为Lock的内部实现。
await() ：造成当前线程在接到信号或被中断之前一直处于等待状态。
await(long time, TimeUnit unit) ：造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。
awaitNanos(long nanosTimeout) ：造成当前线程在接到信号、被中断或到达指定等待时间之前一直处于等待状态。返回值表示剩余时间，如果在nanosTimesout之前唤醒，那么返回值 = nanosTimeout - 消耗时间，如果返回值 <= 0 ,则可以认定它已经超时了。
awaitUninterruptibly() ：造成当前线程在接到信号之前一直处于等待状态。【注意：该方法对中断不敏感】。
awaitUntil(Date deadline) ：造成当前线程在接到信号、被中断或到达指定最后期限之前一直处于等待状态。如果没有到指定时间就被通知，则返回true，否则表示到了指定时间，返回返回false。
signal() ：唤醒一个等待线程。该线程从等待方法返回前必须获得与Condition相关的锁。
signalAll ()：唤醒所有等待线程。能够从等待方法返回的线程必须获得与Condition相关的锁。
三、Condition接口原理简单解析
Condition是AQS的内部类。每个Condition对象都包含一个队列(等待队列)。等待队列是一个FIFO的队列，在队列中的每个节点都包含了一个线程引用，该线程就是在Condition对象上等待的线程，如果一个线程调用了Condition.await()方法，那么该线程将会释放锁、构造成节点加入等待队列并进入等待状态。等待队列的基本结构如下所示。

等待分为首节点和尾节点。当一个线程调用Condition.await()方法，将会以当前线程构造节点，并将节点从尾部加入等待队列。新增节点就是将尾部节点指向新增的节点。节点引用更新本来就是在获取锁以后的操作，所以不需要CAS保证。同时也是线程安全的操作。
3.2、等待
当线程调用了await方法以后。线程就作为队列中的一个节点被加入到等待队列中去了。同时会释放锁的拥有。当从await方法返回的时候。一定会获取condition相关联的锁。当等待队列中的节点被唤醒的时候，则唤醒节点的线程开始尝试获取同步状态。如果不是通过其他线程调用Condition.signal()方法唤醒，而是对等待线程进行中断，则会抛出InterruptedException异常信息。

await方法源码分析

3.2.1、新增等待节点 addConditionWatier()

3.2.2、释放锁 fullyRelease(Node node)

3.2.2.1、release(savedState)

3.2.2.2、释放AQS同步线程锁：tryRelease(arg)

3.2.2.3、唤醒AQS同步线程队列下一个阻塞线程

3.2.3、判断当前线程节点是否是Condition队列
3.2.3.1、判断当前线程节点是否在AQS队列中

3.2.3.2、遍历判断是否是AQS队列（该方法就是从Sync队列尾部开始判断，因为在isOnSyncQueue方法调用该方法时，node.prev一定不为null。但这时的node可能还没有完全添加到Sync队列中（因为node.next是null），这时可能是在自旋中。记得之前说过的enq方法吗，signal的时候会调用这个方法：compareAndSetHead -> compareAndSetTail）

  3.3、通知

在调用signal()方法之前必须先判断是否获取到了锁。接着将会唤醒在等待队列中等待最长时间的节点（条件队列里的首节点），在唤醒节点前，会将节点移到同步队列中并且利用LockSupport唤醒节点中的线程。节点从等待队列移动到同步队列如下图所示：

signal方法源码分析

3.3.1、唤醒线程

3.3.1、唤醒线程 -> 将Condition队列线程增加到AQS队列尾部

3.3.1.1、唤醒线程 -> 将Condition队列线程增加到AQS队列尾部 ->实现

被唤醒的线程将从await方法中的while循环中退出。随后加入到同步状态的竞争当中去。成功获取到竞争的线程则会返回到await方法之前的状态。
四、总结
调用await方法后，将当前线程加入Condition等待队列中。当前线程释放锁。否则别的线程就无法拿到锁而发生死锁。自旋(while)挂起，不断检测节点是否在同步队列中了，如果是则尝试获取锁，否则挂起。当线程被signal方法唤醒，被唤醒的线程将从await()方法中的while循环中退出来，然后调用acquireQueued()方法竞争同步状态。
五、利用Condition实现生产者消费者模式
import java.util.LinkedList;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class BoundedQueue {