java面试相关

1、初始化顺序
父类静态变量->父类静态代码块->子类静态变量->子类静态代码块->父类非静态变量->父类非静态代码块->父类构造方法->子类非静态变量->子类非静态代码块->子类构造方法
总结：先父类静态变量，静态代码块，再子类，先父类非静态变量，非静态代码块，构造，再子类。
2、位运算 >> 由于int型变量只占4Byte(32bit)，因此当右移位数超过32位时，移位运算没有任何意义。因此为保证移位运算的有效性，使右移位数不超过32位，采用了取余的操作，即a>>n 相当于a>>(n%32)
3、rabbitMQ和kafka的区别
rabbitMQ
生产者将消息发送到Exchange（交换器），由Exchange将消息路由到一个或多个Queue中
生产者在将消息发送给Exchange的时候，一般会指定一个routing key，来指定这个消息的路由规则
RabbitMQ中通过Binding将Exchange与Queue关联起来，这样RabbitMQ就知道如何正确地将消息路由到指定的Queue了。在绑定（Binding）Exchange与Queue的同时，一般会指定一个binding key；消费者将消息发送给Exchange时，一般会指定一个routing key；
topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到binding key与routing key相匹配的Queue中，binding key与routing key一样也是句点号“. ”分隔的字符串
1.从社区活跃度
按照目前网络上的资料，RabbitMQ 、activeM 、ZeroMQ 三者中，综合来看，RabbitMQ 是首选。
2.持久化消息比较
ZeroMq 不支持，ActiveMq 和RabbitMq 都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了，消息不会丢失的机制。
3.综合技术实现
可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。
RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。当然ZeroMq 也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。
4.高并发
毋庸置疑，RabbitMQ 最高，原因是它的实现语言是天生具备高并发高可用的erlang 语言。
5.比较关注的比较， RabbitMQ 和 Kafka
RabbitMq 比Kafka 成熟，在可用性上，稳定性上，可靠性上， RabbitMq 胜于 Kafka （理论上）。
另外，Kafka 的定位主要在日志等方面， 因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以 如果业务方面还是建议选择 RabbitMq 。
还有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出来很多。
4、创建一个线程池，核心线程数是2，最大线程数是1，会怎么样
会抛出参数不合法异常IllegalArgumentException
5、线程池种类
1.newSingleThreadExecutor
创建一个单线程的线程池。这个线程池只有一个线程在工作，也就是相当于单线程串行执行所有任务。如果这个唯一的线程因为异常结束，那么会有一个新的线程来替代它。此线程池保证所有任务的执行顺序按照任务的提交顺序执行。
2.newFixedThreadPool
创建固定大小的线程池。每次提交一个任务就创建一个线程，直到线程达到线程池的最大大小。线程池的大小一旦达到最大值就会保持不变，如果某个线程因为执行异常而结束，那么线程池会补充一个新线程。
3.newCachedThreadPool
创建一个可缓存的线程池。如果线程池的大小超过了处理任务所需要的线程，
那么就会回收部分空闲（60秒不执行任务）的线程，当任务数增加时，此线程池又可以智能的添加新线程来处理任务。此线程池不会对线程池大小做限制，线程池大小完全依赖于操作系统（或者说JVM）能够创建的最大线程大小。
4.newScheduledThreadPool
创建一个大小无限的线程池。此线程池支持定时以及周期性执行任务的需求。

线程池按以下行为执行任务
1. 当线程数小于核心线程数时，创建线程。
2. 当线程数大于等于核心线程数，且任务队列未满时，将任务放入任务队列。
3. 当线程数大于等于核心线程数，且任务队列已满
- 若线程数小于最大线程数，创建线程
- 若线程数等于最大线程数，抛出异常，拒绝任务
6、多线程和多进程
多进程和多线程的区别是什么？
　　在Linux下编程多用多进程编程少用多线程编程。
　　IBM有个家伙做了个测试，发现切换线程context的时候，windows比linux快一倍多。进出最快的锁（windows2k的 critical section和linux的pthread_mutex），windows比linux的要快五倍左右。当然这并不是说linux不好，而且在经过实际编程之后，综合来看我觉得linux更适合做high performance server，不过在多线程这个具体的领域内，linux还是稍逊windows一点。这应该是情有可原的，毕竟unix家族都是从多进程过来的，而 windows从头就是多线程的。
　　如果是UNIX/linux环境，采用多线程没必要。
　　多线程比多进程性能高？误导！
　　应该说，多线程比多进程成本低，但性能更低。
　　在UNIX环境，多进程调度开销比多线程调度开销，没有显著区别，就是说，UNIX进程调度效率是很高的。内存消耗方面，二者只差全局数据区，现在内存都很便宜，服务器内存动辄若干G，根本不是问题。
　　多进程是立体交通系统，虽然造价高，上坡下坡多耗点油，但是不堵车。
　　多线程是平面交通系统，造价低，但红绿灯太多，老堵车。
　　我们现在都开跑车，油（主频）有的是，不怕上坡下坡，就怕堵车。
　　高性能交易服务器中间件，如TUXEDO，都是主张多进程的。实际测试表明，TUXEDO性能和并发效率是非常高的。TUXEDO是贝尔实验室的，与UNIX同宗，应该是对UNIX理解最为深刻的，他们的意见应该具有很大的参考意义。
多进程和多线程的优缺点分析：
　　多进程：
　　多进程优点：
　　1、每个进程互相独立，不影响主程序的稳定性，子进程崩溃没关系；
　　2、通过增加CPU，就可以容易扩充性能；
　　3、可以尽量减少线程加锁/解锁的影响，极大提高性能，就算是线程运行的模块算法效率低也没关系；
　　4、每个子进程都有2GB地址空间和相关资源，总体能够达到的性能上限非常大。
　　多进程缺点：
　　1、逻辑控制复杂，需要和主程序交互；
　　2、需要跨进程边界，如果有大数据量传送，就不太好，适合小数据量传送、密集运算 多进程调度开销比较大；
　　3、最好是多进程和多线程结合，即根据实际的需要，每个CPU开启一个子进程，这个子进程开启多线程可以为若干同类型的数据进行处理。当然你也可以利用多线程+多CPU+轮询方式来解决问题……
　　4、方法和手段是多样的，关键是自己看起来实现方便有能够满足要求，代价也合适。
　　多线程：
　　多线程的优点：
　　1、无需跨进程边界；
　　2、程序逻辑和控制方式简单；
　　3、所有线程可以直接共享内存和变量等；
　　4、线程方式消耗的总资源比进程方式好。
　　多线程缺点：
　　1、每个线程与主程序共用地址空间，受限于2GB地址空间；
　　2、线程之间的同步和加锁控制比较麻烦；
　　3、一个线程的崩溃可能影响到整个程序的稳定性；
　　4、到达一定的线程数程度后，即使再增加CPU也无法提高性能，例如Windows Server 2003，大约是1500个左右的线程数就快到极限了（线程堆栈设定为1M），如果设定线程堆栈为2M，还达不到1500个线程总数；
　　5、线程能够提高的总性能有限，而且线程多了之后，线程本身的调度也是一个麻烦事儿，需要消耗较多的CPU。
7、MySQL limit语句
越往后分页，LIMIT语句的偏移量就会越大，速度也会明显变慢。
可以通过子查询的方式来提高分页效率

SELECT * FROM articles WHERE  id >=  
 (SELECT id FROM articles  WHERE category_id = 123 ORDER BY id LIMIT 10000, 1) LIMIT 10  

因为子查询是在索引上完成的，而普通的查询时在数据文件上完成的，通常来说，索引文件要比数据文件小得多，所以操作起来也会更有效率。
实际可以利用类似策略模式的方式去处理分页，比如判断如果是一百页以内，就使用最基本的分页方式，大于一百页，则使用子查询的分页方式。
8、linux查看某个进程是否启动，是否正常
1、 ps -ef | grep xxx 查询xxx进程是否启动
2、查询端口的占用情况netstat -p | grep 3306
3、也可以通过端口号查询进程，使用命令 lsof 比如 lsof -i:6379
9、建表时主键为什么要尽可能自增
B+Tree数是一定有序的，当插入一个乱的节点后，树会重新构建一次，尽可能使用自增主键
10、java两种锁synchronized与lock的对比
类别 synchronized Lock
存在层次 Java的关键字，在jvm层面上 是一个类
锁的释放 1、以获取锁的线程执行完同步代码，释放锁 2、线程执行发生异常，jvm会让线程释放锁 在finally中必须释放锁，不然容易造成线程死锁
锁的获取 假设A线程获得锁，B线程等待。如果A线程阻塞，B线程会一直等待 分情况而定，Lock有多个锁获取的方式，具体下面会说道，大致就是可以尝试获得锁，线程可以不用一直等待
锁状态 无法判断 可以判断
锁类型 可重入 不可中断 非公平 可重入 可判断 可公平（两者皆可）
性能 少量同步 大量同步
11、CDN是什么
CDN主要功能是在不同的地点缓存内容，通过负载均衡技术，将用户的请求定向到最合适的缓存服务器上去获取内容，比如说，是北京的用户，我们让他访问北京的节点，深圳的用户，我们让他访问深圳的节点。通过就近访问，加速用户对网站的访问。解决Internet网络拥堵状况，提高用户访问网络的响应速度。
与传统访问方式不同，CDN网络则是在用户和服务器之间增加缓存层，将用户的访问请求引导到最优的缓存节点而不是服务器源站点，从而加速访问速度。
总结一下CDN的工作原理：通过权威DNS服务器来实现最优节点的选择，通过缓存来减少源站的压力。
12、IO多路复用
I/O多路复用（multiplexing）的本质是通过一种机制（系统内核缓冲I/O数据），让单个进程可以监视多个文件描述符，一旦某个描述符就绪（一般是读就绪或写就绪），能够通知程序进行相应的读写操作
为了实现高并发需要一种机制并发处理多个 socket
Linux 常见的是 select/poll/epoll
可以使用单线程单进程处理多个 socket

select: O(n)
poll: O(n)
epoll: O(1)
13、http协议间区别
http 1.0
·短连接
每一个请求建立一个TCP连接，请求完成后立马断开连接。这将会导致2个问题：连接无法复用，head of line blocking
连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。head of line blocking会导致带宽无法被充分利用，以及后续健康请求被阻塞。
http 1.1
·长连接：
通过http pipelining实现。多个http 请求可以复用一个TCP连接，服务器端按照FIFO原则来处理不同的Request
·增加connection header
该header用来说明客户端与服务器端TCP的连接方式，若connection为close则使用短连接，若connection为keep-alive则使用长连接
·身份认证
·状态管理
·Cache缓存等机制相关的请求头和响应头
·增加Host header
http 2.0
多路复用 (Multiplexing)
多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。在 HTTP/1.1 协议中浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。 HTTP/2 的多路复用(Multiplexing) 则允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接，HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。
二进制分帧
HTTP/2在 应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层。在不改动 HTTP/1.x 的语义、方法、状态码、URI 以及首部字段的情况下, 解决了HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。在二进制分帧层中， HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码 ，其中 HTTP1.x 的首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 里面。
HTTP/2 通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。在过去， HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我调谐，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。
这种单连接多资源的方式，减少服务端的链接压力,内存占用更少,连接吞吐量更大；而且由于 TCP 连接的减少而使网络拥塞状况得以改善，同时慢启动时间的减少,使拥塞和丢包恢复速度更快。
首部压缩（Header Compression）
HTTP/1.1并不支持 HTTP 首部压缩，为此 SPDY 和 HTTP/2 应运而生， SPDY 使用的是通用的DEFLATE 算法，而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。
服务端推送（Server Push）
服务端推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中，服务器可以对客户端的一个请求发送多个响应。Server Push 让 HTTP1.x 时代使用内嵌资源的优化手段变得没有意义；如果一个请求是由你的主页发起的，服务器很可能会响应主页内容、logo 以及样式表，因为它知道客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源，不过与之相比，服务器推送还有一个很大的优势：可以缓存！也让在遵循同源的情况下，不同页面之间可以共享缓存资源成为可能。
14、如何设计高性能、高并发、高可用的系统
系统架构三个利器：RPC服务组件、消息中间件（交互异步化、流量削峰）、配置管理（灰度发布、降级）；
无状态：接口层最重要的就是无状态，将有状态的数据剥离到数据库或缓存中；
如何改善延时：找关键路径（“28原则”）、空间换时间，如各级缓存；时间换空间，如传输压缩，解决网络传输的瓶颈；多核并行，减少锁竞争；更适合的算法和数据结构；通过性能测试和监控找出瓶颈；减少系统调用和上下文切换；
如何提高吞吐量：复制、扩容、异步化、缓存；
如何保障稳定性：提高可用性、分组和隔离、限流、降级、监控和故障切换；
理解高可用系统：要做到数据不丢，就必需要持久化；要做到服务高可用，就必需要有备用（复本），无论是应用结点还是数据结点；要做到复制，就会有数据一致性的问题；我们不可能做到100%的高可用，也就是说，我们能做到几个9个的SLA；
15、分布式，集群
将一套系统拆分成不同子系统部署在不同服务器上（这叫分布式），
然后部署多个相同的子系统在不同的服务器上（这叫集群），部署在不同服务器上的同一个子系统应做负载均衡。
分布式：一个业务拆分为多个子业务，部署在多个服务器上 。
集群：同一个业务，部署在多个服务器上 。
16、zookeeper
它是一个针对大型分布式系统的可靠协调系统，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，可以高可靠的维护元数据。提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper的设计目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

Zookeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。
注意一下这里的"数据"是有限制的：
(1) 从数据大小来看：我们知道ZooKeeper的数据存储在一个叫ReplicatedDataBase 的 数据库中，该数据是一个内存数据库，既然是在内存当中，我就应该知道该数据量就应该不会太大，这一点上就与hadoop的HDFS有了很大的区 别，HDFS的数据主要存储在磁盘上，因此数据存储主要是HDFS的事，而ZooKeeper主要是协调功能，并不是用来存储数据的。
(2) 从数据类型来看：正如前面所说的，ZooKeeper的数据在内存中，由于内存空间的限制，那么我们就不能在上面随心所欲的存储数据，所以ZooKeeper存储的数据都是我们所关心的数据而且数据量还不能太大，而且还会根据我们要以实现的功能来选择相应的数据。简单来说，干什么事存什么数据，ZooKeeper所实现的一切功能，都是由ZK节点的性质和该节点所关联的数据实现的，至于关联什么数据那就要看你干什么事了。
例如：
　　① 集群管理：利用临时节点特性，节点关联的是机器的主机名、IP地址等相关信息，集群单点故障也属于该范畴。
　　② 统一命名：主要利用节点的唯一性和目录节点树结构。
　　③ 配置管理：节点关联的是配置信息。
　　④ 分布式锁：节点关联的是要竞争的资源。
16、负载均衡
https://www.cnblogs.com/ftl1012/p/9570846.html
17、B+树和B树的区别，优缺点
为什么选用B+树作为数据库的索引结构：
1.B+树的中间节点不保存数据，是纯索引,但是B树的中间节点是保存数据和索引的,相对来说,B+树磁盘页能容纳更多节点元素，更“矮胖”；
2.B+树查询必须查找到叶子节点，B树只要匹配到即可不用管元素位置，因此b+树查找更稳定（并不慢）；
3.对于范围查找来说，B+树只需遍历叶子节点链表即可，B树却需要重复地中序遍历,在项目中范围查找又很是常见的
4.增删文件（节点）时，效率更高，因为B+树的叶子节点包含所有关键字，并以有序的链表结构存储，这样可很好提高增删效率。
每建立一个索引，建立一个B+树，但每次查询时只会最多使用到一棵B+树，可以通过EXPLAIN执行计划看到真正使用的索引树。
18、MySQL创建索引的原则，好处
1、 对于查询频率高的字段创建索引；
2、 对排序、分组、联合查询频率高的字段创建索引；
3、 索引的数目不宜太多
原因：a、每创建一个索引都会占用相应的物理控件；
　　 b、过多的索引会导致insert、update、delete语句的执行效率降低；
4、若在实际中，需要将多个列设置索引时，可以采用多列索引
5、选择唯一性索引
唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。
6、尽量使用数据量少的索引
如果索引的值很长，那么查询的速度会受到影响。
7、尽量使用前缀来索引
如果索引字段的值很长，最好使用值的前缀来索引。
8、删除不再使用或者很少使用的索引.
表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理员应当定期找出这些索引，将它们删除，从而减少索引对更新操作的影响
19、什么是rpc框架？和http调用的区别是什么
http接口是基于http协议的post和get接口。rpc接口就相当于调用本地接口一样调用远程服务的接口。
RPC是一种远程过程调用的协议，使用这种协议向另一台计算机上的程序请求服务，不需要了解底层网络技术的协议。
在 RPC 中，发出请求的程序是客户程序，而提供服务的程序是服务器。
一个完整的RPC架构里面包含了四个核心的组件，分别是Client ,Server,Client Stub以及Server Stub，这个Stub大家可以理解为存根。分别说说这几个组件：
客户端（Client），服务的调用方。
服务端（Server），真正的服务提供者。
客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。
RPC框架的好处，首先就是长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
RPC协议与HTTP协议的区别
1、RPC是一种API，HTTP是一种无状态的网络协议。RPC可以基于HTTP协议实现，也可以直接在TCP协议上实现。
2、RPC主要是用在大型网站里面，因为大型网站里面系统繁多，业务线复杂，而且效率优势非常重要的一块，这个时候RPC的优势就比较明显了。
HTTP主要是用在中小型企业里面，业务线没那么繁多的情况下。
3、HTTP开发方便简单、直接。开发一个完善的RPC框架难度比较大。
4、HTTP发明的初衷是为了传送超文本的资源，协议设计的比较复杂，参数传递的方式效率也不高。开源的RPC框架针对远程调用协议上的效率会比HTTP快很多。
5、HTTP需要事先通知，修改Nginx/HAProxy配置。RPC能做到自动通知，不影响上游。
6、HTTP大部分是通过Json来实现的，字节大小和序列化耗时都比Thrift要更消耗性能。RPC，可以基于Thrift实现高效的二进制传输。
20、mysql默认存储引擎？MyISAM、InnoDB、MEMORY的区别
InnoDB 的优势在于提供了良好的事务管理、崩溃修复能力和并发控制
相比 InnoDB ，MyISAM 的优点是处理速度快；缺点是不支持事务处理等。
在MEMORY存储引擎的表中，所有数据都保存在内存中，因此数据的处理速度快，但不能持久保存（程序出错或关机时会丢失数据），而且不能存储太大的数据。对于需要很快的读写速度，但数据量小、不需要持久保存的数据来说，MEMORY存储引擎是一个理想的选择。
ARCHIVE 存储引擎适合保存数量庞大、长期维护但很少被访问的数据，ARCHIVE 存储引擎仅仅支持查询和插入操作，且由于不支持数据索引，查询效率比较低。
21、事务通过什么来实现的
在InnoDB中，给每行增加两个隐藏字段来实现MVCC（多版本并发控制），一个用来记录数据行的创建时间，另一个用来记录行的过期时间（删除时间）。在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。
22、CAS
CAS全称 Compare And Swap（比较与交换），是一种无锁算法。在不使用锁（没有线程被阻塞）的情况下实现多线程之间的变量同步。java.util.concurrent包中的原子类就是通过CAS来实现了乐观锁。
CAS算法涉及到三个操作数：
需要读写的内存值 V。
进行比较的值 A。
要写入的新值 B。
当且仅当 V 的值等于 A 时，CAS通过原子方式用新值B来更新V的值**（“比较+更新”整体是一个原子操作），否则不会执行任何操作。一般情况下，“更新”是一个不断重试的操作。
之前提到java.util.concurrent包中的原子类，就是通过CAS来实现了乐观锁，那么我们进入原子类AtomicInteger的源码，看一下AtomicInteger**的定义：
根据定义我们可以看出各属性的作用：
unsafe： 获取并操作内存的数据。
valueOffset： 存储value在AtomicInteger中的偏移量。
value： 存储AtomicInteger的int值，该属性需要借助volatile关键字保证其在线程间是可见的。
接下来，我们查看AtomicInteger的自增函数incrementAndGet()的源码时，发现自增函数底层调用的是unsafe.getAndAddInt()。但是由于JDK本身只有Unsafe.class，只通过class文件中的参数名，并不能很好的了解方法的作用，所以我们通过OpenJDK 8 来查看Unsafe的源码：
根据OpenJDK 8的源码我们可以看出，**getAndAddInt()循环获取给定对象o中的偏移量处的值v，然后判断内存值是否等于v。如果相等则将内存值设置为 v + delta，否则返回false，继续循环进行重试，直到设置成功才能退出循环，并且将旧值返回。**整个“比较+更新”操作封装在compareAndSwapInt()中，在JNI里是借助于一个CPU指令完成的，属于原子操作，可以保证多个线程都能够看到同一个变量的修改值。
后续JDK通过CPU的cmpxchg指令，去比较寄存器中的 A 和 内存中的值 V。如果相等，就把要写入的新值 B 存入内存中。如果不相等，就将内存值 V 赋值给寄存器中的值 A。然后通过Java代码中的while循环再次调用cmpxchg指令进行重试，直到设置成功为止。
CAS虽然很高效，但是它也存在三大问题，这里也简单说一下：

1. ABA问题。CAS需要在操作值的时候检查内存值是否发生变化，没有发生变化才会更新内存值。但是如果内存值原来是A，后来变成了B，然后又变成了A，那么CAS进行检查时会发现值没有发生变化，但是实际上是有变化的。ABA问题的解决思路就是在变量前面添加版本号，每次变量更新的时候都把版本号加一，这样变化过程就从“A－B－A”变成了“1A－2B－3A”。
   JDK从1.5开始提供了AtomicStampedReference类来解决ABA问题，具体操作封装在compareAndSet()中。compareAndSet()首先检查当前引用和当前标志与预期引用和预期标志是否相等，如果都相等，则以原子方式将引用值和标志的值设置为给定的更新值。
2. 循环时间长开销大。CAS操作如果长时间不成功，会导致其一直自旋，给CPU带来非常大的开销。
3. 只能保证一个共享变量的原子操作。对一个共享变量执行操作时，CAS能够保证原子操作，但是对多个共享变量操作时，CAS是无法保证操作的原子性的。
   Java从1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，可以把多个变量放在一个对象里来进行CAS操作。

23、Java中的锁有什么
可重入锁：在执行对象中所有同步方法不用再次获得锁
可中断锁：在等待获取锁过程中可中断
公平锁： 按等待获取锁的线程的等待时间进行获取，等待时间长的具有优先获取锁权利
读写锁：对资源读取和写入的时候拆分为2部分处理，读的时候可以多线程一起读，写的时候必须同步地写
24、AQS
AQS提供了一种实现阻塞锁和一系列依赖FIFO等待队列的同步器的框架
acquire()的流程：
1.调用自定义同步器的tryAcquire()尝试直接去获取资源，如果成功则直接返回；
2.没成功，则addWaiter()将该线程加入等待队列的尾部，并标记为独占模式；
3.acquireQueued()使线程在等待队列中休息，有机会时（轮到自己，会被unpark()）会去尝试获取资源。获取到资源后才返回。如果在整个等待过程中被中断过，则返回true，否则返回false。
4。如果线程在等待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断selfInterrupt()，将中断补上。
release()是独占模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了（即state=0）,它会唤醒等待队列里的其他线程来获取资源。
25、ArrayList是如何添加元素的？删除元素后会自动缩小空间吗
ArrayList 底层是数组的形式，所以支持重复元素，如果没有指定大小，默认容量为10，当超过的默认容量的时候，会进行扩容，按照原来容量的1.5倍加1进行。当存入的集合数量一直增加时，会一直进行扩容操作
ArrayList不会自动缩小容积,有一个方法可以缩小容积
public void trimToSize() {
modCount++;
if (size < elementData.length) {
elementData = Arrays.copyOf(elementData, size);
}
}