常见的面试题

基础的部分

ThreadLocal

1.Thread里有个属性是ThradLocalMap（和每个线程绑定，每个线程私有）,可以通过ThraedLocal（ThreadLocal和Thread在一个包里）来操作Thread里的ThreadLocalMap。
2.ThreadLocalMap通过一个Entry数组来保存数据，Entry的key是ThreadLocal类型的，value是Object类型的，key是一种弱引用类型的引用。
3.ThreadLocal的使用场景一般是用来在单个线程中的方法之中传递数据。
4.内存溢出：没有足够的内存来分配。内存泄漏：无法释放申请的内存空间，内存泄漏的堆积导致内存溢出。
5.重写initialValue代表的是value的类型，一般是使用hashmap。
6.注意事项：
脏数据问题：线程复用导致产生脏数据，由于线程池会复用Thread对象，进而Thread对象中的threalLocals也会被复用，导致Thread对象在执行其他任务时通过get()方法获取到之前线程设置的数据，从而产生脏数据。
内存泄漏问题：如果开发人员单纯寄希望于ThreadLocal对象失去引用后，触发弱引用机制来回收Entry的Value，那么就会导致内存泄漏，Entry的Value无法被回收。
解决方法：执行完线程的逻辑体之后调用ThreadLocal的remove方法进行移除。

spring framework的部分

spring

1.BeanFactory和FactoryBean的区别：BeanFactory是spring容器的访问入口（可以认为是spring容器），FactoryBean是用户自己实现的用来生产自己所需的对象的工厂。
2.整个spring的启动逻辑：
	（1）先读取配置文件，把配置的bean封装成一个个的BeanDefinied。
	（2）然后根据BeanDefinied创建对象并且初始化。
3.bean的生命周期：
	（1）实例化（就是根据反射创建对象，此时属性都被初始化为零值）。
	（2）初始化：首先调用对象的set方法设置属性，然后看是否实现了aware接口（用来获取spring容器使用的对象），然后再执行BeanBostProcesser的before和after方法。
	（3）获取并使用对象。
	（4）spring容器关闭，单例对象销毁。

zookeeper

1.zk是一种分布式协调的工具，它提供了文件系统（采用了文件系统的结构，每一个节点都用一个路径来表示，可以存储1m的数据）和通知机制。分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
2.提供了以下操作：create 、delete、get 、set  、get children、sync、existes.
3.zk非常快速和简单。但是，由于它的目标是作为构建更复杂服务(如同步)的基础，因此它提供了一组保证:
	顺序一致性：来自客户端的更新将按照它们发送的顺序应用。
	原子性：更新成功或失败。没有部分结果。
	单一视图：客户机将看到服务的相同视图，而不管它连接到哪个服务器。也就是说，即使客户端故障转移到具有相同会话的不同服务器上，客户端也永远不会看到系统的旧视图。
	可靠性：一旦更新被应用，它将从那时起一直持续，直到客户端覆盖更新。
	及时性：系统的客户端视图保证在一定的时间范围内是最新的。
4.分为四种类型的节点：临时节点（会话失效节点就会被删除）、持久节点、临时序列节点、持久序列节点。
5.zk有三个角色：
	Leader
	（1）事务请求（节点的增删改操作）的唯一调度和处理者，保证集群事务处理的顺序性
	（2）集群内部各服务的调度者
  Folllower
	（1）处理客户端的非事务请求（节点的查询操作），转发事务请求给 Leader 服务器
	（2）参与事务请求提议的投票
	（3）参与 Leader 选举投票
 Observer
	（1）3.0 版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力
   （2）处理客户端的非事务请求，转发事务请求给 Leader 服务器
   （3）不参与任何形式的投票
6.zk集群节点有四种状态：
	（1）LOOKING：寻 找 Leader 状态。当服务器处于该状态时，它会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。
	
	（2）FOLLOWING：跟随者状态。表明当前服务器角色是 Follower。
	
	（3）LEADING：领导者状态。表明当前服务器角色是 Leader。
	
	（4）OBSERVING：观察者状态。表明当前服务器角色是 Observer。
7.过半（leader和follow的投票要大于数量的一半）机制的使用场景：在进行leader选举的时候，投票数要过半，在进行提议通过的时候也要进行过半同意提议才会被通过。
8. zookeeper 是如何保证事务的顺序一致性：
	zookeeper 采用了全局递增的事务 Id 来标识，所有的 proposal（提议）都在被leader提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字，高 32 位是 epoch（ 时期; 纪元; 世; 新时代）用来标识 leader 周期，如果有新的 leader 产生出来，epoch会自增，低 32 位用来递增计数。当新产生 proposal 的时候，会依据数据库的两阶段过程，首先会向其他的 follower发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。
9.java 客户端：zk 自带的 zkclient 及 Apache 开源的 Curator。
10.什么场景下回触发leader选举：
	zk集群启动或者是重新启动的时候、leader节点挂掉的时候、集群死掉的可用节点（leader和follower）节点<=可用节点的一半时（此时集群对外不可用）。
11.两阶段提交过程：
	（1）首先leader节点会把提议发送给follower节点
	（2）follower节点会记录事务日志,将执行结果发送给leader节点
	（3）leader节点收到通知以后，如果过半同意，会向所有的follower节点发送执行命令
12.Zookeeper Watcher 机制 – 数据变更通知：
	Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。

	工作机制：
	
	（1）客户端注册 watcher
	
	（2）服务端处理 watcher
	
	（3）客户端回调 watcher
	
	Watcher 特性总结：
	
	（1）一次性
	
	无论是服务端还是客户端，一旦一个 Watcher 被 触 发 ，Zookeeper 都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力，不然对于更新非常频繁的节点，服务端会不断的向客户端发送事件通知，无论对于网络还是服务端的压力都非常大。
	
	（2）客户端串行执行
	
	客户端 Watcher 回调的过程是一个串行同步的过程。
	
	（3）轻量
	
	3.1、Watcher 通知非常简单，只会告诉客户端发生了事件，而不会说明事件的具体内容。
	
	3.2、客户端向服务端注册 Watcher 的时候，并不会把客户端真实的 Watcher 对象实体传递到服务端，仅仅是在客户端请求中使用 boolean 类型属性进行了标记。
	
	（4）watcher event 异步发送 watcher 的通知事件从 server 发送到 client 是异步的，这就存在一个问题，不同的客户端和服务器之间通过 socket 进行通信，由于网络延迟或其他因素导致客户端在不通的时刻监听到事件，由于 Zookeeper 本身提供了 ordering guarantee，即客户端监听事件后，才会感知它所监视 znode发生了变化。所以我们使用 Zookeeper 不能期望能够监控到节点每次的变化。Zookeeper 只能保证最终的一致性，而无法保证强一致性。
	
	（5）注册 watcher getData、exists、getChildren
	
	（6）触发 watcher create、delete、setData
	
	（7）当一个客户端连接到一个新的服务器上时，watch 将会被以任意会话事件触发。当与一个服务器失去连接的时候，是无法接收到 watch 的。而当 client 重新连接时，如果需要的话，所有先前注册过的 watch，都会被重新注册。通常这是完全透明的。只有在一个特殊情况下，watch 可能会丢失：对于一个未创建的 znode的 exist watch，如果在客户端断开连接期间被创建了，并且随后在客户端连接上之前又删除了，这种情况下，这个 watch 事件可能会被丢失。
13.Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。
14.zookeeper主要是根据ZAB协议是实现分布式系统数据一致性。zab协议包含两个模式：消息广播、崩溃恢复（leader节点崩溃），相关的内容链接：https://www.cnblogs.com/frankltf/p/10392151.html。
15.zab是对Paxos的简化和优化。

消息队列的部分（rocketmq）

rpc框架的部分

redis的部分

1.redis是一种以KV存储的非关系型数据库。redis使用单线程来处理客户端的请求，但是对于事件的处理(持久化、主从复制)都是再开启一个进程进行异步处理的。
2.redis的应用场景：
3.redis命令的原子性：
	（1）redis的单个命令都是具有原子性的。
	（2）提供了原生的批操作处理的命令像是mget，mset。
	（3）原生的批操作处理的命令只能操作单个key，可以通过管道一次性发送的多条命令，但是管道发送的多个命令不具有原子性，可以通过lua脚本实现一次执行多条命令并且具备原子性。
	（4）事务不具备原子性：语法错误（像是java的编译错误）会全部回滚，命令错误（像是java的运行错误）已经执行成功的不会回滚。
2.速度快的原因：基于内存读写；单线程处理客户端的请求，预防了多线程可能产生的竞争问题；Redis是用C语言实现的，一般来说C语言实现的程序“距离”操作系统更 近，执行速度相对会更快。
3.数据持久化的方式RDB和AOF:
	（1）RDB（存储的是真正的数据）使用命令bgsave（save已经不使用，会阻塞主线程),会先执行fork(),然后会在后台开启一个进程来执行持久化操作,可以通过命令手动执行，也可以通过配置文件配自动执行。
	（2）AOF（存储的是对数据的修改命令）使用命令bgrewriteaof（本质是把数据转换为set命令）自动触发重写，也可以通过配置文件配置，先执行fork()，然后开启子进程把数据转换为写命令写入新的AOF文件，然后把aof的重写缓冲区的命令写入，最后替换掉旧的AOF文件。
	（3）fork执行的操作是把主进程的逻辑地址和物理地址的对应关系拷贝一份，修改数据时，采用了copy on  write机制，保证了进程之间的数据隔离。
	（4）AOF重写会让文件变小：会删除过期的key，会删除对于同一个key的多个命令，会把set命令进行合并。
	（5）RDB默认开启，AOF默认关闭，当两者都开启时，会选择AOF。
	（6）RDB和AOF的优缺点：RDB恢复速度快（因为存储的是数据，AOF存储的屙是命令），AOF具有实时性（可以每次把修改命令记录到日志）。
	(7) AOF可以选择命令的刷盘规则，推荐的是先写入aof缓冲区，然后再写入系统缓冲区，再开启一个进程执行每秒的刷盘操作。
4.为了解决单机故障和进行读写分离提升效率，redis一般采用主从复制的方式来部署：
	（1）一般是一个master节点，多个slave节点，master节点可以用来读写，slave一般只能用来读。
	（2）从节点使用命令slaveof(replicationof高版本使用)来连接到主节点。
	（3）全量复制：触发时机：会在第一次连接时、当进行部分复制时，偏移量不在复制积压缓冲区内。执行步骤：会开启一个线程执行持久化生成RDB文件（可以配置是否写入本地磁盘），然后把文件和复制缓冲区的内容发送给从节点，从节点接收到数据之后，会先清空本身的数据，然后加载数据和复制缓冲区的内容。如果开启了AOF还要执行bgrewriteaof。
	（4）部分复制：触发时机：从节点断开后重新连接到master并且数据需要的数据在复制积压缓冲区。执行步骤：slave会发送master id和自身的复制偏移量，master把master offset - slave offset的数据发送给slave,slave加载。
	（5）主从复制的缺点：一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同时需 要修改应用方的主节点地址，还需要命令其他从节点去复制新的主节点，整 个过程都需要人工干预；主节点的写能力受到单机的限制；主节点的存储能力受到单机的限制。
5.哨兵模式（为了解决master故障需要人为干预的问题）：
6.缓存常见的问题  https://blog.csdn.net/kongtiao5/article/details/82771694：
	（1）缓存击穿：发生场景：在高并发场景下，某一个key或者是几个key过期（数据库有数据，缓存没数据）。解决方案：对设置一个锁，只允许一个线程去访问数据库（为了防止死锁，给锁设置过期时间）。
	（2）缓存穿透：发生场景：在高并发场景下，请求不存在的数据（数据库和和缓存都没有数据）。解决方案：对于不存的key设置null.
	（3）缓存雪崩：发生场景:高并发场景下，大量key过期（数据库有数据，缓存没数据）。解决方案：设置不同的过期时间。

分布式系统

1.分布式系统？
	分布在不同服务器上的程序协同对外界提供服务形成的整体。
2.数据一致性的分类？
	强一致性：在某个数据节点上修改了数据，其他的数据节点可以立刻读到更新后的数据。
	弱一致性：没有一致性，不同的数据节点可以读到不同的数据。
	最终一致性：在某个数据节点上修改了数据，在其他的数据节点最终可以读到更新后的数据。
3.CAP?
	C（Consistency）指的是强一致性。P（Partition tolerance）：指的是分区容错性，当某个节点挂掉时，分布式系统仍然可用,这是分布式系统的基础。
	A（Availability）：指的是可用性，系统可以对用户的请求作出正常的响应，不能是请求超时或者是请求错误（错误不是指业务错误）。	
4.为什么只能满足CPA里的两个？
	C如果要保证强一致性，必须要在不同的数据节点之间进行实时的同步，同步为完成之前无法对外界提供服务，会与A产生矛盾。
5.BASE?
	BA（Basically Available）:基本上可用，系统可以部分不可用，但是核心服务必须可用。S（Soft state）:软状态，在数据的最终一致性之前加入的一些中间状态。E（Eventually consistent）:最终一致性。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

分布式事务

1.分布式事务的分类？
	在单个服务的某个方法中使用不同的数据库。
	在单个服务的某个方法中调用其他服务的数据库方法。
分布式事务解决方案：
2.2PC（two-phase commit protocol）?
	介绍：两阶段提交，第一阶段为预处理，第二阶段为提交或者是回滚。事务管理器（协调者）会向数据库实例（参与者）发送预提交命令，参与者会进行响应，如果都是true协调者会通知参与者进行提交，否则会进行回滚。
	缺点：
	（1）性能问题
	  无论是在第一阶段的过程中,还是在第二阶段,所有的参与者资源和协调者资源都是被锁住的,只有当参与者准备完毕，事务协调者才会通知进行全局提交。参与者 进行本地事务提交后才会释放资源，这样的过程会比较漫长，对性能影响比较大。
    （2）单节点故障
	  由于协调者的重要性，一旦 协调者 发生故障。参与者 会一直阻塞下去。尤其在第二阶段，协调者 发生故障，那么所有的 参与者 还都处于锁定事务资源的状态中，而无法继续完成事务操作。（虽然协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）。
    （3）消息丢失
     丢失消息导致的数据不一致问题。在第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就会导致节点间数据的不一致问题。
 3.3PC（three-phase commit protocol）?
	介绍：三阶段提交协议（3PC）主要是为了解决两阶段提交协议的阻塞问题，2pc存在的问题是当协作者崩溃时，参与者不能做出最后的选择。因此参与者可能在协作者恢复之前保持阻塞。三阶段提交（Three-phase commit），是二阶段提交（2PC）的改进版本。
	
    三阶段提交有两个改动点：
	（1） 引入超时机制。同时在协调者和参与者中都引入超时机制。
    （2）在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
  
   三个阶段：
   （1）CanCommit阶段：事务询问：协调者向参与者发送CanCommit请求，询问是否可以执行事务提交操作，然后开始等待参与者的响应。响应反馈：参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态，否则反馈No。
   （2）PreCommit阶段：在阶段一中，如果所有的参与者都返回Yes的话，那么就会进入PreCommit阶段进行事务预提交。这里的PreCommit阶段 跟上面的第一阶段是差不多的，只不过这里 协调者和参与者都引入了超时机制 （2PC中只有协调者可以超时，参与者没有超时机制）。
   （3）这里跟2pc的阶段二是差不多的。
  
    总结：相比较2PC而言，3PC对于协调者（Coordinator）和参与者（Partcipant）都设置了超时时间，而2PC只有协调者才拥有超时机制。这解决了一个什么问题呢？这个优化点，主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。另外，通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。以上就是3PC相对于2PC的一个提高（相对缓解了2PC中的前两个问题），但是3PC依然没有完全解决数据不一致的问题。
4.tcc（Try-Confirm-Cancel）？
	tcc指的是补偿事务，分为三个操作。try：业务系统做检测及资源预留。commit：确认执行业务操作。cancle：取消执行业务操作。

杂篇

1.什么是幂等性？
	用户对于同一操作的一次或者是多次请求产生的影响是相同的。
	这里的影响指的是对于系统数据的改变或者是系统运行状态的改变，不是指操作的返回结果。