最近面试的Coder们，你们对结果还满意吗？今天给大家总结下Java面试中常见的问题和应对策略，虽然可能好多人认为我把那些面试中常见的记下就行了，但你确定你真的都能记得住吗。尤其对中高级的Java开发来说，有经验的面试官问的知识点都很广，你想全部记住基本可能性不大。所以，技巧和策略很重要。我们先说说Java面试中的基础问题吧。
1，Jvm的内存结构
这道面试题对Java高级开发来说基本必问，主要考察面试者对JVM内存结构的理解，堆内存中新生代和老年代的划分及运作、以及垃圾回收。
详解请看下面的文章。
2，谈谈你对Java垃圾回收的理解？
这个是JVM原理及内存结构引深的话题，我们知道，Java垃圾回收就是针对JVM内存结构中的堆内存而言的。这里涉及的问题：
1），垃圾回收时对象存活的判断方法？
2），垃圾回收算法？
3），垃圾收集器有哪几种及原理？
详解请看下面的文章。
3，Java中有那些锁，说说他们的实现原理？
这是中大型公司对Java中高级开发者几乎必问的话题，关于锁的面试题中Synchronized是重点被问的对象。Java锁也是并发编程必须要掌握的知识点。
具体请看：Java中的锁及实现原理
4，Java中有哪些连接池？
常见的Java连接池有：C3P0，DBCP，Proxool，Druid等。
目前最常用的是Druid。连接池的特点及原理大家也需要了解下，这里不做解释。
5，说说你用过的集合，及实现原理？
这个题一方面考察应聘者对Java集合基础知识的掌握，同时也考察应聘者的知识深度及相关扩展。扩展的知识点就是CurrentHashMap，最好结合HashMap和HashTable去讲讲CurrentHashMap的实现原理，这是绝对的加分项。
HashMap、CurrentHashMap及HashTable的区别：
- HashMap是线程不安全，CurrentHashMap和HashTable是线程安全的；
- ConcurrentHashMap对整个Hash桶数组进行了分段，而HashMap和HashTable没有；
- ConcurrentHashMap在每一个分段上都用锁进行保护，从而让锁的粒度更精细一些，并发性能更好，而HashTable是对整个桶上锁
- ConcurrentHashMap实现线程安全效率比HashTable高；
6，多个线程如何实现顺序执行？
这个题主要考察你对多线程的理解情况，可以通过线程的join()方法实现。
7，说说事务隔离级别？
1）、未提交读（Read uncommitted）
就是一个事务读取到其他事务未提交的数据，是级别最低的隔离机制。缺点是会产生脏读、不可重复读、幻读。
2）、提交读（Read committed)
就是一个事务读取到其他事务提交后的数据。Oracle默认隔离级别。缺点是会产生不可重复读、幻读。
3）、可重复读（Repeatable read）
就是一个事务对同一份数据读取到的相同，不在乎其他事务对数据的修改。MySQL默认的隔离级别。缺点为会产生幻读。
4）、序列化（Serializable）
事务串行化执行，隔离级别最高，牺牲了系统的并发性。缺点：可以解决并发事务的所有问题。但是效率低下，消耗数据库性能，一般不使用。
注：Spring项目中，事务隔离级别配置使用isolation关键词，如下所示：@Transactional(isolation=Isolation.DEFAULT)，DEFAULT为数据源的默认隔离级别。
8，说说你用过哪些索引，及对索引的理解？
这里主要以Mysql数据库为例展开说明。一般项目中用的最多的就是：主键索引、唯一索引、组合索引。
Mysql索引数据结构为B Tree。对不同存储引擎来说，InnoDB的数据文件本身就是索引文件，B Tree的叶子节点上的data就是数据本身，key为主键，这是聚簇索引。而MyISAM引擎使用B Tree作为索引结构，叶节点的data域存放的是数据记录的地址。
9，Dubbo支持哪些通信协议？
- dubbo 协议 (默认)； 单一长连接，NIO异步通信，基于hessian序列化协议。
- rmi 协议； 走java二进制序列化，多个短连接，适合消费者和提供者数量差不多，适用于文件的传输，一般较少用。
- hessian 协议； 走hessian序列化协议，多个短连接，适用于提供者数量比消费者数量还多，适用于文件的传输，一般较少用；
- http 协议； 走json序列化
- webservice 协议；走SOAP文本序列化
- redis 协议
- rest ( 就是 RestFull)
10，Dubbo服务失败默认重试几次，如何配置？
在Dubbo服务的提供者中，超时默认重试2次。可通过retries关键词设置。如：
代码语言：javascript复制<dubbo:service interface="com.***" ref="demoService" retries="0" timeout="5000"/>11，Dubbo提供者在集群时对消费端如何实现负载均衡？
Dubbo提供者的负载均衡通过配置loadbalance实现。Dubbo实现负载均衡的策略：按权重随机分配、轮询、一致性Hash、最少访问调用。
1）、按权重随机分配； 这是Dubbo提供者默认的负载均衡策略。按权重随机分配，即是不均等随机事件。比如一块不均匀的硬币，字面30%概率，花面70%概率。这种就是不均等的随机事件
2）、轮询； 当多线程出现时，使用原子类的整数去取莫轮询节点。注意：sequences是成员变量，每次调用函数所有的权重都回归最初。
3）、一致性Hash；使用一致性hash算法，同一请求总是会hash到同一台机子上。一致性hash算法把请求，节点都hash后，放到一个圆环上，按照顺时针转动到的第一个节点为结果。这样就减少了结果的变化。还可以通过增加虚拟节点的方式均衡hash后的概率问题，当然增加节点需要交叉增加。
4）、最少访问调用； 如果有多台机器的最少活跃数相同，在这几个中使用第一种按权重随机的方式。最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
12，Zookeeper的有几种角色及选举机制？
Zookeeper主要有三种角色，分别如下：
Zookeeper选举机制
目前有3台服务器，每台服务器均没有数据，它们的编号分别是1,2,3按编号依次启动，它们的选择举过程如下：
- 服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。
- 服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
- 服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
ZK中每个Server在工作过程中有三种状态：
- LOOKING：当前Server不知道leader是谁，正在搜寻
- LEADING：当前Server即为选举出来的leader
- FOLLOWING：leader已经选举出来，当前Server与之同步
13，分布式锁你是如何实现的？
首先告诉面试官你用分布式解决了什么问题。实际分布式锁也是跟Java锁一样，都是为了解决并发环境下对接口的操作。目前主流的分布式锁实现方案：
1，redis分布式锁；
2，Zookeeper分布式锁
他们二者的对比：
获取锁：Redis分布式锁是通过创建key，如果创建成功就获取了锁；而在Zookeeper是通过创建同一个临时节点，因为Zookeeper节点命名路径保证唯一，只要谁能够先创建成功，谁能够获取到锁。
释放锁 ：Redis在释放锁的时候，为了确保是锁的一致性问题，在删除的redis 的key时候，需要判断同一个锁的id，才可以删除。Zookeeper使用直接关闭临时节点session会话连接，因为临时节点生命周期与session会话绑定在一块，如果session会话连接关闭的话，该临时节点也会被删除。
解决死锁：Redis 是对key设置有效期解决死锁现象，Zookeeper使用会话有效期方式解决死锁现象。
性能方面：因为Redis是NoSQL数据库，相对比来说Redis比Zookeeper性能要好。
可靠性：从可靠性角度分析，Zookeeper可靠性比Redis更好。
14，说说你项目中分布式事务的实现方案？
分布式事务解决方案通常有两种：TCC补偿式事务和可靠消息最终一致性。
二者的区别：
1，TCC是通过try...confirm...cancel实时处理，而消息最终一致性一般都是非实时处理；
2，TCC使分布式系统服务内聚，不利于扩展；而消息最终一致性可以实现系统解耦，更有利于系统后期的扩展；
其实他们两还有很多区别与特点，如果面试官问道你这个话题，除了告诉他你有了那个技术解决分布式事务外，还一定要告诉他你为什么选用这个解决方案。不管任何技术的选用都基于业务，没有那个好那个坏。
15，说说你在项目中遇到的问题及解决方案？
这是对有工作经验的面试者常用到的话题。也是用来考察应聘者思考问题及解决问题的能力。如果你们遇到了这个问题，一定要慎重回到。就算你已经总结了好了几个应对的答案，但不建议记着回答。可以先告诉面试者让我想想，先思考10-30s，然后再去回答。这是一个开放性的问题，没有确切的答案，只是看你总结的到位不到位，切记，不要告诉面试官遇的问题是由于你自己的代码不谨慎造成的。
参考：分布式环境下编号唯一性生成方案（分布式环境中某个服务集群，在并发情况下造成编号重复问题解决方案）。
