史上最全的中高级JAVA工程师-面试题汇总_java高级程序员面试题

原理：基本上哪个哨兵节点最先判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制Raft算法（选举算法），最终被投为领导者的哨兵节点完成主从自动化切换的过程。

集群模式

redis3.0之后的容错集群方式，无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接，需要至少三个master提供写的功能。
  因此集群中至少应该有奇数个节点，因此至少有三个节点，每个节点至少有一个备份节点，所以redis集群应该至少6个节点。
  每个Master有一个范围的slot槽位用于写数据。

Redis可以在线扩容吗？zk呢

Reids的在线扩容，不需要重启服务器，动态的在原始集群中添加新的节点,并分配slot槽。
但是zk不能在线扩容，需要重启，但是我们可以选择一个一个重启。

Redis高并发和快速的原因

1.redis是基于内存的，内存的读写速度非常快；
2.redis是单线程的，省去了很多上下文切换线程的时间；
3.redis使用多路复用技术，可以处理并发的连接。
缺点：无法发挥多核CPU性能

浏览器本地缓存的了解和使用

资源在浏览器端的本地缓存可以通过Expires和Last-Modified返回头信息进行有效控制。

1）Expires告诉浏览器在该指定过期时间前再次访问同一URL时，直接从本地缓存读取，无需再向服务器发起http请求；
  优点是：浏览器直接读取缓存信息无需发起http请求。
   缺点是：当用户按F5或Ctl+F5刷新页面时浏览器会再次发起http请求。

2）当服务器返回设置了Last-Modified头，下次发起同一URL的请求时，请求头会自动包含If-Modified-Since头信息，服务器对静态内容会根据该信息跟文件的最后修改时间做比较，如果最后修改时间不大于If-Modified-Since头信息，则返回304：告诉浏览器请求内容未更新可直接使用本地缓存。
（注意：只对静态内容有效，如js/css/image/html等，不包括动态内容，如JSP）
优点：无论用户行为如何都有效；
缺点：仍需向服务器发起一次http请求；

缓存雪崩

如果缓存集中在一段时间内失效，发生大量的缓存穿透，所有的查询都落在数据库上，造成了缓存雪崩。

解决办法：
没有完美的解决方案，可以通过随机算法让失效时间随机分布，避免同一时刻失效。

缓存穿透

访问一个不存在的key，缓存不起作用，请求会穿透到DB，可能DB也没查到，流量大时DB会挂掉。

解决办法：
1.采用布隆过滤器，使用一个足够大的bitmap，用于存储可能访问的key，不存在的key直接被过滤；
2访问key未在DB查询到值，也将空值写进缓存，但可以设置较短过期时间。

HashMap

HashMap的Hash碰撞

  Hash值冲突问题是Hash表存储模型需要解决的一个问题。通常有两种方法：
  将相同Hash值的Entry对象组织成一个链表放置在hash值对应的槽位。HashMap采用的是链表法，且是单向链表（通过head元素就可以操作后续所有元素，对链表而言，新加入的节点会从头节点加入。）
核心源码：

private void addEntry(int hash, K key, V value, int bucketIndex) {  
    Entry<K,V> e = table[bucketIndex];  
    table[bucketIndex] = new Entry<K,V>(hash, key, value, e);  
    if (size++ >= threshold)  
        resize(2 \* table.length);  
}

以上代码说明：
系统总是将新添加的 Entry 对象放入 table 数组的 bucketIndex 索引处。
1 如果 bucketIndex 索引处已经有了一个 Entry 对象，那新添加的 Entry 对象指向原有的 Entry 对象
（产生一个 Entry 链）
2 如果 bucketIndex 索引处没有 Entry 对象，也就是上面程序代码的 e 变量是 null，也就是新放入的
Entry 对象指向 null，也就是没有产生 Entry 链。
HashMap里面没有出现hash冲突时，没有形成单链表时，hashmap查找元素很快,get()方法能够直接定位到元素，
但是出现单链表后，单个bucket 里存储的不是一个 Entry，而是一个 Entry 链，系统只能必须按顺序遍历每个
Entry，直到找到想搜索的 Entry 为止——如果恰好要搜索的 Entry 位于该 Entry 链的最末端（该 Entry 是最早
放入该 bucket 中），那系统必须循环到最后才能找到该元素。

HashMap的get和put原理

PUT原理：
当调用HashMap的put方法传递key和value时，先调用key的hashcode方法。
通过key的Hash值来找到Bucket----‘桶’的位置，然后迭代这个位置的Entry列表
判断是否存在key的hashcode和equals完全相同的key，如果完全相同则覆盖value，
否则插入到entry链的头部。

HashMap在put时的Entry链形成的场景？

当程序试图将一个key-value对放入HashMap中时，程序首先根据该 key 的 hashCode() 返回值决定该 Entry 的存储位置：
如果这两个 Entry 的 key 的 hashCode() 返回值相同，那它们的存储位置相同。
如果这两个 Entry 的 key 通过 equals 比较返回 true，新添加 Entry 的 value 将覆盖集合中原有 Entry 的 value，但key不会覆盖。

如果这两个 Entry 的 key 通过 equals 比较返回 false，新添加的 Entry 将与集合中原有 Entry 形成 Entry 链，而且新添加的 Entry 位于 Entry 链的头部

GET原理：
根据该 key 的 hashCode 值计算它的 hash 码，遍历并循环取出 Entry 数组中指定索引处的Entry值，如果该 Entry 的 key 与被搜索 key 相同 ，且Enrty的hash值跟key的hash码相同，然后看是否是Entry链，如果是则迭代这个位置的Entry列表,判断是否存在key的hashcode和equals完全相同的key，如果完全相同则获取value。

HashMap的rehash

HashMap初始容量大小为16,一般来说，当有数据要插入时，都会检查容量有没有超过设定的thredhold，如果超过，需要增大Hash表的尺寸，但是这样一来，整个Hash表里的元素都需要被重算一遍。这叫rehash，这个成本相当的大

HashMap的线程不安全问题

比如put操作时，有两个线程A和B，首先A希望插入一个key-value对到HashMap中，首先计算记录所要落到的桶的索引BucketIndex坐标，然后获取到该桶里面的Entry链表header头结点，此时线程A的时间片用完了，而此时线程B被调度得以执行，和线程A一样执行，只不过线程B成功将记录插到了桶里面，假设线程A插入的记录计算出来的桶索引和线程B要插入的记录计算出来的桶索引是一样的，那么当线程B成功插入之后，线程A再次被调度运行时，它依然持有过期的链表头但是它对此一无所知，以至于它认为它应该这样做，如此一来就覆盖了线程B插入的记录，这样线程B插入的记录就凭空消失了，造成了数据不一致的行为。
参考：https://www.cnblogs.com/qiumingcheng/p/5259892.html
另一个不安全的体现是扩容操作可能由于resize而导致死循环。
参考：https://www.zhihu.com/question/28516433

HashMap和Hashtable的区别

相同点：
1 都实现了Map接口
2 Hashtable和HashMap采用的hash/rehash算法都大概一样，所以性能不会有很大的差异

不同点：
1 hashMap允许NULL作为key和value，而hashtable不允许
2 hashMap线程不安全，Hashtable线程安全
3 hashMap速度快于hashtable
4 HashMap 把 Hashtable的contains方法去掉了，改成containsvalue和containsKey,避免引起误会
5 Hashtable是基于陈旧的Dictionary类的，HashMap是Java 1.2引进的Map接口的一个实现

为什么collection没有实现clonable接口

Collection接口有很多不同的集合实现形式，而clonable只对具体的对象有意义。

为什map没有实现collection接口

Set 和List 都继承了Conllection，Map没有继承于Collection接口，Map提供的是key-Value的映射，而Collection代表一组对象。

Map接口的实现有哪些,区别是什么

HashMap,LinkedHashMap,Hashtable,TreeMap。

LinkedHashMap 是HashMap的一个子类，保存了记录的插入顺序
Hashtable和HashMap类似，它继承自Dictionary类，不同的是它不允许键或值为空。
TreeMap实现SortMap接口，能够把它保存的记录根据键排序,默认是按键值的升序排序，也可以指定排序的比较器

线程池

Executors框架的四种线程池及拒绝策略

四种线程池

ExecutorService executorService =
固定大小线程池

Executors.newFixedThreadPool(60);
设置固定值会造成高并发线程排队等待空闲线程，尤其是当读取大数据量时线程处理时间长而不释放线程，导致无法创建新线程。

可缓存线程池
Executors.newCachedThreadPool();
线程池无限大，而系统资源（内存等）有限，会导致机器内存溢出OOM。

定长且可定时、周期线程池
Executors.newScheduledThreadPool(5);

单线程线程池
Executors.newSingledThreadPool();

/\* 自定义线程池。
 \* 构造参数：
 \* public ThreadPoolExecutor(
 \* int corePoolSize,--当前线程池核心线程数
 \* int maximumPoolSize,--当前线程池最大线程数
 \* long keepAliveTime,--保持活着的空间时间
 \* TimeUnit unit,--时间单位
 \* BlockingQueue<Runnable> workQueue,--排队等待的自定义队列
 \* ThreadFactoty threadFactory,
 \* RejectedExecutionHandler handler--队列满以后，其他任务被拒绝执行的方法
 \* ){.........}

在使用有界队列时，若有新的任务需要执行，

• 若线程池实际线程数小于corePoolSize，则优先创建线程，
• 若大于corePoolSize，则会将任务加入队列，
• 若队列已满，则在总线程数不大于maximumPoolSize的前提下，创建新的线程，
• 若线程数大于maximumPoolSize，则执行拒绝策略。或其他自定义方式。

JDK拒绝策略

• AbortPolicy：默认，直接抛出异常，系统正常工作。
• DiscardOldestPolicy:丢弃最老的一个请求，尝试再次提交当前任务。
• CallerRunsPolicy:只要线程池未关闭，该策略直接在调用者线程中，运行当前被丢弃的任务。用线程池中的线程执行，而是交给调用方来执行, 如果添加到线程池失败，那么主线程会自己去执行该任务，不会等待线程池中的线程去执行

new ThreadPoolExecutor(   
   2, 3, 30, TimeUnit.SECONDS,    
    new SynchronousQueue<Runnable>(),    
    new RecorderThreadFactory("CookieRecorderPool"),    
     new ThreadPoolExecutor.CallerRunsPolicy());  

• DiscardPolicy：丢弃无法处理的任务，不给予任何处理。
• 自定义拒绝策略
  如果需要自定义策略，可以实现RejectedExecutionHandler接口。

Reactor模式

参考：https://www.cnblogs.com/duanxz/p/3696849.html

Reactor单线程模型

一个Acceptor线程，监听Accept事件，负责接收客户端的连接SocketChannel，SocketChannel注册到Selector上并关心可读可写事件。
一个Reactor线程，负责轮训selector，将selector注册的就绪事件的key读取出来，拿出attach任务Handler根据事件类型分别去执行读写等。

单线程模型的瓶颈：
比如：拿一个客户端来说，进行多次请求，如果Handler中数据读出来后处理的速度比较慢（非IO操作：解码-计算-编码-返回）会造成客户端的请求被积压，导致响应变慢！
所以引入Reactor多线程模型！

Reactor多线程模型

Reactor多线程就是把Handler中的IO操作，非IO操作分开。
操作IO的线程称为IO线程，操作非IO的线程叫做工作线程。
客户端的请求（IO操作：读取出来的数据）可以直接放进工作线程池（非IO操作：解码-计算-编码-返回）中，这样异步处理，客户端发送的请求就得到返回了不会一直阻塞在Handler中。
但是当用户进一步增加的时候，Reactor线程又会出现瓶颈，因为Reactor中既有IO操作，又要响应连接请求。为了分担Reactor的负担，所以引入了主从Reactor模型!

主从Reactor模型

  主Reactor用于响应连接请求，从Reactor用于处理IO操作请求！
  特点是：服务端用于接收客户端连接的不再是1个单独的NIO线程（Acceptor线程），而是一个独立的NIO线程池。
  Acceptor线程池接收到客户端TCP连接请求处理完成后（可能包含接入认证等），将新创建的SocketChannel注册到I/O线程池（sub reactor线程池）的某个I/O线程上，由它负责SocketChannel的读写和编解码工作。
  Acceptor线程池只用于客户端的登录、握手和安全认证，一旦链路建立成功，就将链路注册到后端subReactor线程池的I/O线程上，有I/O线程负责后续的I/O操作。
  第三种模型比起第二种模型，是将Reactor分成两部分，mainReactor负责监听server socket，accept新连接，并将建立的socket分派给subReactor。subReactor负责多路分离已连接的socket，读写网 络数据，对业务处理功能，其扔给worker线程池完成。通常，subReactor个数上可与CPU个数等同。

JVM

Object的内存布局

方法区卸载Class的条件

1 该类所有的实例已经被回收
2 加载该类的ClassLoader已经被回收
4该类对应的java.lang.Class对象没有任何地方被引用

Ps：方法区除了回收无用class，也回收废弃常量，即没有被引用常量

可以作为GC Roots的对象包括哪些

虚拟机栈（栈帧中的局部变量表）中引用的变量
方法区中类静态属性引用的对象
方法区中常量引用的对象
本地方法栈中JNI引用的变量

JVM运行时内存模型

方法区、堆、虚拟机栈、本地方法栈、程序计数器

Netty的ByteBuffer的引用计数器机制

从netty的4.x版本开始，netty使用引用计数机制进行部分对象的管理，通过该机制netty可以很好的实现自己的共享资源池。
如果应用需要一个资源，可以从netty自己的共享资源池中获取，新获取的资源对象的引用计数被初始化为1，可以通过资源对象的retain方法增加引用计数，当引用计数为0的时候该资源对象拥有的资源将会被回收。

判断对象是否存活的两种方法

1 引用计数法：缺点是对循环引用的对象无法回收
2 可达性分析

Java对象的初始化过程

类加载双亲委派模型

从上到下分三个类加载器：

BootStrap classloader：启动类加载器，负责将Java_HOME/lib下的类库加载到虚拟机内存中，比如rt.jar
Extension classloader:扩展类加载器，负责将JAVA_HOME/lib/ext下的类库加载到虚拟机内存中。
Application classloader：应用程序类加载器，负责加载classpath环境变量下指定的类库。如果程序中没有自定义过类加载器，那么这个就是程序中默认的类加载器。

双亲委派模型：

如果一个类加载器收到类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器完成。每个类加载器都是如此，只有当父加载器在自己的搜索范围内找不到指定的类时（即ClassNotFoundException），子加载器才会尝试自己去加载。

防止自定义的一些跟jdk标准库中冲突的全限定名的类被加载，导致标准库函数不可用。

Zookeeper

Zookeeper的常用应用场景有哪些

• 分布式锁：获取父节点下的最小节点作为获得锁的一方
• 命名服务：通过在zookeeper节点下创建全局唯一的一个path
• 配置管理：配置放在zk上，所有应用监听节点改变。
• 集群管理:GroupMembers集群管理，是否有机器退出和加入

Zookeeper的分布式数据一致性算法

ZAB原子消息广播协议。

一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。

参考：
http://www.360doc.com/content/16/0823/11/14513665_585293946.shtml
ZAB协议定义了选举（election）、发现（discovery）、同步（sync）、广播(Broadcast)四个阶段；

Zk启动过程的Leader选举分析及数据同步

参考：http://www.cnblogs.com/leesf456/p/6107600.html

Zookeeper数据同步的简单描述

在ZooKeeper中所有的客户端事务请求都由一个主服务器也就是Leader来处理，其他服务器为Follower，Leader将客户端的事务请求转换为事务Proposal，并且将Proposal分发给集群中其他所有的Follower，然后Leader等待Follwer反馈，当有过半数（>=N/2+1）的Follower反馈信息后，Leader将再次向集群内Follower广播Commit信息，Commit为将之前的Proposal提交；

ZK集群最少需要几台机器？

三台，2N+1，保证奇数，主要是为了leader选举算法中的“超过半数有效（>=N/2+1）”

Zookeeper和Eureka的区别

答：ZK保证Cp,即一致性，分区容错性，比如当master节点因为网络故障和其他节点失去联系的时候，剩余节点会重新进行Master选举。问题在于Master选举的时间太长30~210s，选举期间整个zk集群是不可用的，这就导致选举期间的注册服务瘫痪。
  Eureka保证Ap，高可用性，它没有所谓主从节点概念，各节点平等。某节点挂掉不影响其他节点功能，其他节点照样提供查询和注册功能。Eureka客户端发现Eureka节点挂掉直接切换到其他正常的节点上去。只不过可能查到的数据不是最新的，也就是Eureka不保证数据的强一致性。
  作为注册中心，推荐Eureka，因为注册服务更重要的是可用性。

Mysql

InnoDB和MyISAM存储引擎的区别

Starting from MySQL 5.5.5, the default storage engine for new tables isInnoDB rather than MyISAM.

Btree索引和Hash索引的区别

Btree索引适合范围查找，Hash索引适合精确查找

数据库的ACID特性

数据库事务必须具备ACID特性
原子性：Atomic，所有的操作执行成功，才算整个事务成功
一致性：Consistency，不管事务success或fail，不能破坏关系数据的完整性以及业务逻辑上的一致性
隔离性：Isolation，每个事务拥有独立数据空间，多个事务的数据修改相互隔离。事务查看数据更新时，数据要么是另一个事务修改前的状态，要么是修改后状态，不应该查看到中间状态数据。
持久性：Durability，事务执行成功，数据必须永久保存。重启DB，数据需要恢复到事务执行成功后的状态。
原子性、一致性、持久性DBMS通过日志来实现。
  隔离性DBMS通过锁来实现

Mysql数据库的隔离级别

M

Select For Update使用场景

select for update 的使用场景，为了避免自己看到的数据并不是数据库存储的最新数据并且看到的数据只能由自己修改，需要用 for update 来限制。

分布式事务模型之XA和TCC的区别和联系？

XA-DTP模型

最早的分布式事务模型是 X/Open 国际联盟提出的 X/Open Distributed Transaction Processing（DTP）模型，也就是大家常说的 X/Open XA 协议，简称XA 协议。
  DTP 模型中包含一个全局事务管理器（TM，Transaction Manager）和多个资源管理器（RM，Resource Manager）。全局事务管理器负责管理全局事务状态与参与的资源，协同资源一起提交或回滚；资源管理器则负责具体的资源操作。

TCC模型

TCC（Try-Confirm-Cancel）分布式事务模型相对于 XA 等传统模型，其特征在于它不依赖资源管理器（RM）对分布式事务的支持，而是通过对业务逻辑的分解来实现分布式事务。
Try-Confirm-Cancel
Try 操作对应2PC 的一阶段准备（Prepare）；Confirm 对应 2PC 的二阶段提交（Commit），Cancel 对应 2PC 的二阶段回滚（Rollback），可以说 TCC 就是应用层的 2PC。

参考：
https://mp.weixin.qq.com/s?__biz=MzUzMzU5Mjc1Nw==&mid=2247483681&idx=1&sn=05845495c5ef33683addd98fffc72106&chksm=faa0eefbcdd767edbf46cea6f223b426e276dd4d9b19cce64f59387590818f5e4eb96c7d2533&mpshare=1&scene=2&srcid=0118GSYShGZaOyCndUoAqsae&from=timeline#rd

Mysql-binlog日志复制方式

①基于段的复制
记录的是执行的语句
②基于行的复制
记录是表中每一行的操作
③混合复制

mysql主从复制原理

从服务器的IO线程读取主服务器的二进制日志变更，写入到中继日志relaylog中，如果IO线程追赶上了主服务器的日志，则进入sleep状态，直到主服务器发送唤醒信号，从服务器上的SQL线程重放relaylog中的日志。

基于日志点的复制和GTID的复制有何区别？

基于日志点的复制：从主服务器的哪个二进制日志的偏移量进行增量同步，如果指定错误会造成遗漏或重复。
基于GTID的复制：从服务器会告诉主服务器，已经在从服务器上已经执行完了哪些gtid值，然后主库会把从库未执行的事务gtid值发送给从库执行。同一个事务只在指定的从库上执行一次。

Mysql性能诊断和优化

聚簇索引和非聚簇索引的区别

聚簇索引，就是指主索引文件和数据文件为同一份文件，聚簇索引主要用在Innodb存储引擎中。如主键。B+Tree的叶子节点上的data就是数据本身。
非聚簇索引就是指B+Tree的叶子节点上的data，并不是数据本身，而是数据存放的地址

消息队列

消费者宕机：怎么保证消息队列消息不丢失？

比如activemq或者rabbitmq生产者消息投递到消息队列后，消费者拿到消息后，默认是自动签收机制，消息队列将删除这条消息，但是如果仅仅是拿到但是没有来得及处理业务逻辑时，消费者就宕机，那么此消息将会丢失，以后也不会再收到。
解决办法：
  消费端要设置签收机制为手动签收，只有当消息最终被处理，才告诉消息队列已经消费，此时消息队列再删除这条消息。

MQ集群宕机：怎么保证消息不丢失？

生产者投递消息到mq服务器，如果不保证消息和队列的持久化，那么当mq宕机时消息将彻底丢失，所以需要对消息做持久化存储，可以存储到磁盘或者数据库中，当mq服务器恢复时，消费端可以继续消费mq服务器中的消息。

但是，比如RabbitMQ的消息持久化，是不承诺100%的消息不丢失的！
 &emsp**;原因**：因为有可能RabbitMQ接收到了消息，但是还没来得及持久化到磁盘，他自己就宕机了，这个时候消息还是会丢失的。如果要完全100%保证写入RabbitMQ的数据必须落地磁盘，不会丢失，需要依靠其他的机制。

参考：
https://mp.weixin.qq.com/s/ZAWPRToPQFcwzHBf47jZ-A
https://mp.weixin.qq.com/s/HwAc6o8jdIHQTnE3ghXhIA
https://mp.weixin.qq.com/s/AEn3j2lVJOHZx9yegwTsvw
https://mp.weixin.qq.com/s/uqWIf0MAet_StszuOrZCwQ
https://mp.weixin.qq.com/s/9SFrwaCCLnNyuCqP_KQ0zw
https://mp.weixin.qq.com/s/vZ4KVC2eGmssnQUyIKgzfw
https://mp.weixin.qq.com/s/r2_o5wa6Gn94NY4ViRnjpA

Spring源码系列

springmvc如何解决循环依赖的问题

当使用构造器方式初始化一个bean，而且此时多个Bean之间有循环依赖的情况，spring容器就会抛出异常！
解决办法：初始化bean的时候（注意此时的bean必须是单例，否则不能提前暴露一个创建中的bean）使用set方法进行注入属性，此时bean对象会先执行构造器实例化，接着将实例化后的bean放入一个map中，并提供引用。当需要通过set方式设置bean的属性的时候，spring容器就会从map中取出被实例化的bean。比如A对象需要set注入B对象，那么从Map中取出B对象即可。以此类推，不会出现循环依赖的异常。

spring事务的传播行为和隔离级别

spring事务七个事务传播行为

在TransactionDefinition接口中定义了七个事务传播行为：

• PROPAGATION_REQUIRED 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。
• PROPAGATION_SUPPORTS 如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。但是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少许不同。
• PROPAGATION_MANDATORY 如果已经存在一个事务，支持当前事务。如果没有一个活动的事务，则抛出异常。
• PROPAGATION_REQUIRES_NEW 总是开启一个新的事务。如果一个事务已经存在，则将这个存在的事务挂起。
• PROPAGATION_NOT_SUPPORTED 总是非事务地执行，并挂起任何存在的事务。
• PROPAGATION_NEVER 总是非事务地执行，如果存在一个活动事务，则抛出异常
• PROPAGATION_NESTED如果一个活动的事务存在，则运行在一个嵌套的事务中. 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行

Spring事务的五种隔离级别

在TransactionDefinition接口中定义了五个不同的事务隔离级别

• ISOLATION_DEFAULT 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.
  另外四个与JDBC的隔离级别相对应
• ISOLATION_READ_UNCOMMITTED 这是事务最低的隔离级别，它充许别外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读
• ISOLATION_READ_COMMITTED 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这种事务隔离级别可以避免脏读出现，但是可能会出现不可重复读和幻像读。
• ISOLATION_REPEATABLE_READ 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。
• ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读外，还避免了幻像读。

设计模式

单例模式

1懒汉模式-非安全
懒汉模式（线程不安全，可能出现多个Singleton 实例）

public class Singleton { 
    private static Singleton instance; 
    private Singleton (){} 

    public static Singleton getInstance() { 
    		if (instance == null) { 
           instance = new Singleton(); 
    		} 
    		return instance; 
    } 
}

2懒汉模式-安全
懒汉模式 （线程安全）

public class Singleton { 
    private static Singleton instance; 
private Singleton (){} 

    public static synchronized Singleton getInstance() { 
    		if (instance == null) { 
        	 instance = new Singleton(); 
    		} 
    		return instance; 
    } 
}  

3饿汉模式

public class Singleton { 
    private static Singleton instance = new Singleton(); 
    private Singleton (){} 
    public static Singleton getInstance() { 
         return instance; 
    } 
}

4饿汉模式（变种）
饿汉（变种，跟第三种差不多，都是在类初始化即实例化instance）

public class Singleton { 
    private Singleton instance = null; 
    static { 
    		instance = new Singleton(); 
    } 
    private Singleton (){} 
    public static Singleton getInstance() { 
    		return this.instance; 
    } 
}

5静态内部类
静态内部类，跟三四有细微差别：
Singleton类被装载instance不一定被初始化，因为内部类SingletonHolder没有被主动使用，只有显示调用getInstance才会显示装载SingletonHolder 类，从而实例化instance

public class Singleton { 
    private static class SingletonHolder { 
         private static final Singleton INSTANCE = new Singleton(); 
    } 
    private Singleton (){} 
    public static final Singleton getInstance() { 
         return SingletonHolder.INSTANCE; 
    } 
}   

6枚举
枚举（既可以避免多线程同步问题，还可以防止被反序列化重建对象）

public enum Singleton { 
    INSTANCE;
public void whateverMethod() {
	   
} 

public static void main(String[] args) {
		Singleton s = Singleton.INSTANCE;
		Singleton s2 = Singleton.INSTANCE;
		System.out.println(s==s2);
}

}

**输出结果：**true
  说明这种方式创建的对象是同一个，因为枚举类中的INSTANCE是static final类型的，只能被实例化一次。对于Enum中每一个枚举实例，都是相当于一个单独的Singleton实例。所以借用 《Effective Java》一书中的话，
单元素的枚举类型已经成为实现Singleton的最佳方法

7懒汉升级版

public class Singleton { 
    private volatile static Singleton singleton; 
    private Singleton (){} 
    public static Singleton getSingleton() { 
    		if (singleton == null) { 
        		synchronized (Singleton.class) { 
        			if (singleton == null) { 
          			  	singleton = new Singleton(); 
       			 } 
        		} 
    		} 
    		return singleton; 
    	} 
}

策略模式

JDK源码

ThreadLocal的实现原理

ThreadLocal的实现原理,有什么缺点？跟线程池结合使用要注意什么

原理：Current Thread当前线程中有一个ThreadLocalMap对象，它的key是ThreadLocal的弱引用，Value是ThreadLocal调用set方法设置的对象值。每一个线程维护一个各自的ThreadLocalMap，所以多个线程之间变量相互隔离，互不干扰。

缺点：存在内存泄漏问题，因为当ThreadLocal设置为null后，ThreadLocalMap的key的弱引用指向了null，又没有任何的强引用指向threadlocal，所以threadlocal会被GC回收掉。但是，ThreadLocalMap的Value不会被回收，CurrentThread当前线程的强引用指向了ThreadLocalMap，进而指向了这个Entry<key,value>,所以只有当currentThread结束强引用断开后，currentThread、ThreadLocalMap、Entry将全部被GC回收。
所以结论是：
  只要currentThread被GC回收，就不会出现内存泄漏。
但是在currentThread被GC回收之前，threadlocal设置为null之后的这段时间里，Value不会被回收，比如当使用线程池的时候，线程结束不会被GC回收，会被继续复用，那这个Value肯定还会继续存在。如果这个Value很大的情况下，可能就会内存泄漏。
虽然threadlocal的set和get方法执行时会清除key为null的value，但是如果当前线程在使用中没有调用threadlocal的set或者get方法一样可能会内存泄漏。

跟线程池结合使用的注意事项：
  因为线程池中线程复用的情况，本次的threadlocal中可能已经存在数据，所以上一次使用完threadlocal的变量后，要调用threadlocal的remove方法清除value。而且要注意调用完remove后应该保证不会再调用get方法。

AQS实现公平锁和非公平锁

基于AQS的锁(比如ReentrantLock)原理大体是这样:

• 有一个state变量，初始值为0，假设当前线程为A,每当A获取一次锁，status++. 释放一次，status–.锁会记录当前持有的线程。
• 当A线程拥有锁的时候，status>0. B线程尝试获取锁的时候会对这个status有一个CAS(0,1)的操作，尝试几次失败后就挂起线程，进入一个等待队列。
• 如果A线程恰好释放，–status==0, A线程会去唤醒等待队列中第一个线程，即刚刚进入等待队列的B线程，B线程被唤醒之后回去检查这个status的值，尝试CAS(0,1),而如果这时恰好C线程也尝试去争抢这把锁。

非公平锁实现：
C直接尝试对这个status CAS(0,1)操作，并成功改变了status的值，B线程获取锁失败，再次挂起，这就是非公平锁，B在C之前尝试获取锁，而最终是C抢到了锁。
公平锁：
C发现有线程在等待队列，直接将自己进入等待队列并挂起,B获取锁

RPC

RPC的序列化方式有哪些

Thrift—facebook
ProtoBuf—google
Hessian
JAVA原生的序列化接口
Json/xml

服务熔断与服务降级概念

计算机网络

• HTTP 缓存

• 你知道 302 状态码是什么嘛？你平时浏览网页的过程中遇到过哪些 302 的场景？

• HTTP 常用的请求方式，区别和用途？

• HTTPS 是什么？具体流程

• 三次握手和四次挥手

• 你对 TCP 滑动窗口有了解嘛？

• WebSocket与Ajax的区别

• 了解 WebSocket 嘛？

• HTTP 如何实现长连接？在什么时候会超时？

• TCP 如何保证有效传输及拥塞控制原理。

• TCP 协议怎么保证可靠的，UDP 为什么不可靠？

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

算法

• 链表

• 字符串

• 数组问题

• 二叉树

• 排序算法

• 二分查找

• 动态规划

• BFS

• 栈

• DFS

• 回溯算法