volatile在多级Cache中是如何实现的？
靠的缓存一致性协议实现的，当cpu写数据时，如果发现操作的变量是共享变量，那么在对该变量进行写入的时候，会使其他cpu将该变量的缓存设置为无效状态，当其他cpu需要读取变量时，再重新从内存中去读取
进程池？
就是创建适当的进程在进程池里，和线程池的原理类似，都是为了避免重复地销毁或创建，在处理完任务后进程不销毁，而是继续在进程池中等待
步骤：1.创建进程池，在池内放入合适的进程
2.将事件加入到进程池的等待队列
3.使用进程池内的进程不断的执行事件，直到所有事件执行完毕
4.所有事件处理完毕后，关闭进程池
操作：pool（创建进程池对象） apply_asyn（异步地将要执行的事件放入进程池） apply（按照顺序添加执行事件）
进程有几种状态？
就绪状态
执行状态
阻塞状态
http包含什么？
请求行 请求头 请求数据 响应行 响应头 响应体
请求行由方法字段，url，http协议版本组成：get /baidu.html http/1.1
tcp1.0,1.1,2.0的区别？
1.1是默认长连接的，1.0需要主动建立，1.1支持只发送header信息而不用发送请求体，可以节约带宽，1.1还支持host域
2.0支持多路复用（即一个连接处理并发请求多次，如果数据并没有准备好，用户线程还可以去做其他事而不会被阻塞在这里），并且支持数据压缩（用的hpack算法，传输速度更快），支持服务器推送，服务端会把相关的客户端需要的数据一并传输过去（比如静态文件）
dubbo的ref和id？
service层中引用dubbo服务时，ref的值就是想要暴露的接口的实现类的名字，id的值是要调用的接口的名字
tcp的流量控制和拥塞控制？
tcp流量控制（滑动窗口）：
流量控制就是让发送方的发送速率不要太快，要让接收方来得及接受，原理是通过确认报文中窗口字段来控制发送方的发送速率，发送方的发送窗口大小不能超过接收方给出的窗口大小。
这个时候可能接收方向发送方发送了零窗口的报文段后，接收方又有了新的存储空间，而接收方向发送方发送非零窗口的报文段出现了丢失，发送方的发送窗口会一直为零导致死锁，为了解决这个问题，为每个连接设置了持续计时器，只要接收方一收到零窗口通知，就会启动持续计时器，如果时间到期，就会发送一个零窗口探测报文段，这个时候对方要确认窗口值，如果窗口仍为0，则收到报文段的一方重置持续计时器
tcp的拥塞控制：
为了防止过多的数据注入到网络中，为了控制发送方的速率，但是流量控制是为了让接收方来得及接收，而拥塞控制是为了降低整个网络的拥塞程度（是全局性的）
做法：发送方让自己的发送窗口等于拥塞窗口，拥塞窗口的大小取决于网络的拥塞程度，并且动态变化
1.数据是单向传送的，对方只传送确认报文
2.接收方总是有足够大的缓存空间，因而发送窗口的大小由网络的拥塞程度决定
慢开始和拥塞避免：发送的最初执行慢开始，令cwnd=1，也就是发送方只能发送1个报文段，收到确认后，cwnd加倍，当cwnd大于ssthresh（慢开始门限）时，改为拥塞避免算法（也就是每经过一个往返cwnd加1），当cwnd=ssthresh时，既可以采用慢开始，也可以采用拥塞避免算法，当cwnd小于ssthresh时，使用慢开始算法，当网络超时时，将ssthresh设置为cwnd/2，同时设置拥塞窗口cwnd=1，开始慢开始算法
快重传：快重传要求接收方在接收到一个失序的报文段后就立即发送重复确认而不是等到自己发送数据时才确认。快重传规定发送方只要一连收到三个重复确认就应当立即重传对方未收到的报文段，而不是等到重传计时时间到期。
快恢复：当发送方连续收到3个重复确认时，执行乘法减小算法，把ssthresh门限减半，但是此时把cwnd设置为ssthresh的大小，然后执行的是拥塞避免算法
https的原理？
https就是带有ssl的http，它在http上加了一层处理加密信息的模块，服务端和客户端之间传输的数据都是加密后的数据
流程：
1.客户端发起https请求：输入一个https网址，然后连接到server的443端口
2.服务端拥有一套数字证书（该数字证书就是一对公钥和私钥）
3.服务端将证书传送给客户端，客户端验证证书是否有效，如果异常，则弹出警告信息，没有问题就生成随机值，然后对随机值进行加密，再把加密后的随机值发送给服务端，这样以后服务端和客户端的通信就可以通过该随机值来进行加密解密了，服务端用私钥解密后，得到客户端传送过来的随机值，然后进行对称加密，再把加密信息传送给客户端，客户端进行解密
也就是所谓的用对称加密传送信息，但是对称加密使用的密钥通过非对称加密的方式发送出去
osi七层协议与tcp/ip四层协议（架构）？
七层：应用层 表示层 会话层 传输层 网络层 数据链路层 物理层
四层：应用层 传输层 网络层 数据链路层
产生大量time_wait的原因及危害？
如果某些服务（ftp/pop）是服务端在收到客户端的quit命令后主动关闭连接，这就会造成容易出现大量time_wait状态的连接，当客户端程序忘记关闭连接时也容易出现time_wait。但是大量的time_wait也不好，因为它占用了资源导致不能创建更多的socket，socket的数量是有限的，最多65535，并且过多的time_wait也会占用内存，一个占4kb
解决方法：调整time_wait的超时时间（优化到30s）
为什么mysql的索引选择了B+树而不是红黑树？
红黑树一般是存储在内存中才会使用的数据结构，而索引是存放在磁盘中的，当存储大量数据时，红黑树由于深度过大的原因会导致磁盘io过于频繁，进而导致效率低下（因为要获取磁盘上的数据，必须先通过磁盘移动臂移动到数据所在的页面，然后找到指定盘面，接着找到数据所在的磁道，最后才进行读写），而红黑树的深度过大导致磁盘io频繁读写。而B+树可以有多个子女就能够降低树的高度以此来减少磁盘io。它将节点的大小设为等于一个页，这样每个节点只需要一次io就可以完全载入
联合索引的B+树？
b+树的非叶子节点存储的是联合索引key的键值对，并且按照一定顺序在节点间排队，对于InnoDB，叶子结点存储是联合索引key的键值对+主键索引，myisAm存储的是联合索引key键值对+data内存地址
jdk自带线程池的缺陷？
1.非核心线程的创建是在核心线程已满并且阻塞队列也满了的情况下才创建的，这个时候假如拒绝策略是抛弃任务的话，那么当大量的任务到达时可能就会都被抛弃掉
2.当线程池核心线程数量满了，阻塞队列也满了，这个时候新加的任务被非核心线程执行，这样的话先提交的任务反而后执行了，假如任务之间有依赖关系，那么就会降低线程的调度效率
优化：1.自定义一个等待队列，当队列中的任务达到一定数量时就去创建非核心线程而不是满了才创建。可以使用LinkedBlockingQueue，产生一个双生产者，单消费者的模型，其中生产者分为普通生产者和超限生产者
2. 采用代理类，将任务绑定时间延迟到任务执行时而不是添加的时候，增加新的任务队列，按添加顺序保证真正的执行任务，运行时动态地从新增任务中获取头部任务
手写max函数使用泛型，能够支持Comparator接口，或者说可以支持对对象排序
首先是泛型T，然后为了支持Comparator接口，所以要extends Comparable，接着就是具体的比较t1.compareTo(t2)了，这里由于是比较最大值，所以我判断的是结果大于0返回t1，小于0返回t2。如果T就是一个int或者float型的，那么直接比较就行，如果是一个对象，那么那个对象需要实现Comparable接口，并且重写compareTo（）方法
java序列化的原理？
可以实现Serializable接口，这样的话javac进行编译时就会进行特殊处理，编译的类就可以被writeObject方法所操作。其实Serializable是一个空接口，没有任何方法，只是标明该对象可被序列化
tcp的缺陷？
由于传递数据需要三次握手来建立连接，所以速度慢，并且由于tcp的确认机制和三次握手机制，可能会收到dos攻击（通过发送大量的半连接请求也就是syn洪水攻击，消耗cpu和内存资源：客户端短时间伪造大量不存在的ip地址，向服务器不断发送syn包，服务器恢复ack并等待客户的确认，但是ip地址实际上不存在，所以服务器需要不断地重发）
HashMap的底层数据结构？
哈希表（数组+链表），结合了数组和链表的优点，当链表长度大于8时，转换为红黑树
jvm的安全点？
可达性分析算法必须确保是在一个一致的内存快照中进行的，安全点就意味着在这个点时，所有的工作线程都是确定的，这个时候jvm就可以安全地执行GC。安全点太多的话，GC过于频繁，太少的话，等待时间过长
怎么选定安全点：循环的末尾，方法返回前，调用方法后，抛出异常时的位置。主要就是为了避免程序长时间无法进入安全点
如何在GC发生时，所有线程都跑到最近的安全点上停下来：
抢占式中断：在GC发生时，中断所有线程，如果发现线程没有执行到安全点，则恢复线程让其运行到安全点上
主动式中断：GC发生时，不直接操作线程中断，而是设置一个标记，让各个线程执行时主动轮询这个标志，发现中断标志为真时自己中断挂起（jvm采用的是主动式中断）
