刚看完黑马教程的新版Java面试专题视频教程，java八股文面试全套真题+深度详解（含大厂高频面试真题），对面试题分专题整理，方便面试突击

Redis相关面试题

Redis相关面试题
面试官：什么是缓存穿透 ? 怎么解决 ?
候选人：
嗯，我想一下，缓存穿透是指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致DB 挂掉。这种情况大概率是遭到了攻击。解决方案的话，我们通常都会用布隆过滤器来解决它
面试官：好的，你能介绍一下布隆过滤器吗？
候选人：
嗯，是这样~，布隆过滤器主要是用于检索一个元素是否在一个集合中。我们当时使用的是redisson实现的布隆过滤器。它的底层主要是先去初始化一个比较大数组，里面存放的二进制0或1。在一开始都是0，当一个key来了之后经过3次hash计算，模于数组长度找到数据的下标，然后把数组中原来的0改为1，这样的话，三个数组的位置就能标明一个key的存在。查找的过程也是一样的。
当然是有缺点的，布隆过滤器有可能会产生一定的误判，我们一般可以设置这个误判率，大概不会超过5%，其实这个误判是必然存在的，要不就得增加数组的长度，其实已经算是很划分了，5%以内的误判率一般的项目也能接受，不至于高并发下压倒数据库。
面试官：什么是缓存击穿 ? 怎么解决 ?
候选人：
嗯！！缓存击穿的意思是对于设置了过期时间的key，缓存在某个时间点过期的时候，恰好这时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。
解决方案有两种方式：
第一可以使用互斥锁：当缓存失效时，不立即去load db，先使用如 Redis 的setnx 去设置一个互斥锁，当操作成功返回时再进行 load db的操作并回设缓存，否则重试get缓存的方法
第二种方案可以设置当前key逻辑过期，大概是思路如下：
①：在设置key的时候，设置一个过期时间字段一块存入缓存中，不给当前key设置过期时间
②：当查询的时候，从redis取出数据后判断时间是否过期
③：如果过期则开通另外一个线程进行数据同步，当前线程正常返回数据，这个数据不是最新
当然两种方案各有利弊：
如果选择数据的强一致性，建议使用分布式锁的方案，性能上可能没那么高，锁需要等，也有可能产生死锁的问题
如果选择key的逻辑删除，则优先考虑的高可用性，性能比较高，但是数据同步这块做不到强一致。
面试官：什么是缓存雪崩 ? 怎么解决 ?
候选人：
嗯！！缓存雪崩意思是设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多key，击穿是某一个key缓存。
解决方案主要是可以将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
面试官：redis做为缓存，mysql的数据如何与redis进行同步呢？（双写一致性）
候选人：嗯！就说我最近做的这个项目，里面有xxxx（根据自己的简历上写）的功能，需要让数据库与redis高度保持一致，因为要求时效性比较高，我们当时采用的读写锁保证的强一致性。我们采用的是redisson实现的读写锁，在读的时候添加共享锁，可以保证读读不互斥，读写互斥。当我们更新数据的时候，添加排他锁，它是读写，读读都互斥，这样就能保证在写数据的同时是不会让其他线程读数据的，避免了脏数据。这里面需要注意的是读方法和写方法上需要使用同一把锁才行。
面试官：那这个排他锁是如何保证读写、读读互斥的呢？
候选人：其实排他锁底层使用也是setnx，保证了同时只能有一个线程操作锁住的方法
面试官：你听说过延时双删吗？为什么不用它呢？
候选人：延迟双删，如果是写操作，我们先把缓存中的数据删除，然后更新数据库，最后再延时删除缓存中的数据，其中这个延时多久不太好确定，在延时的过程中可能会出现脏数据，并不能保证强一致性，所以没有采用它。
面试官：redis做为缓存，mysql的数据如何与redis进行同步呢？（双写一致性）
候选人：嗯！就说我最近做的这个项目，里面有xxxx（根据自己的简历上写）的功能，数据同步可以有一定的延时（符合大部分业务）我们当时采用的阿里的canal组件实现数据同步：不需要更改业务代码，部署一个canal服务。canal服务把自己伪装成mysql的一个从节点，当mysql数据更新以后，canal会读取binlog数据，然后在通过canal的客户端获取到数据，更新缓存即可。
面试官：redis做为缓存，数据的持久化是怎么做的？
候选人：在Redis中提供了两种数据持久化的方式：1、RDB 2、AOF
面试官：这两种持久化方式有什么区别呢？
候选人：RDB是一个快照文件，它是把redis内存存储的数据写到磁盘上，当redis实例宕机恢复数据的时候，方便从RDB的快照文件中恢复数据。AOF的含义是追加文件，当redis操作写命令的时候，都会存储这个文件中，当redis实例宕机恢复数据的时候，会从这个文件中再次执行一遍命令来恢复数据
面试官：这两种方式，哪种恢复的比较快呢？
候选人：RDB因为是二进制文件，在保存的时候体积也是比较小的，它恢复的比较快，但是它有可能会丢数据，我们通常在项目中也会使用AOF来恢复数据，虽然AOF恢复的速度慢一些，但是它丢数据的风险要小很多，在AOF文件中可以设置刷盘策略，我们当时设置的就是每秒批量写入一次命令
面试官：Redis的数据过期策略有哪些 ?
候选人：
嗯~，在redis中提供了两种数据过期删除策略。第一种是惰性删除，在设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key。第二种是 定期删除，就是说每隔一段时间，我们就对一些key进行检查，删除里面过期的key
定期清理的两种模式：
SLOW模式是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件redis.conf 的 hz 选项来调整这个次数。FAST模式执行频率不固定，每次事件循环会尝试执行，但两次间隔不低于2ms，每次耗时不超过1ms
Redis的过期删除策略：惰性删除 + 定期删除两种策略进行配合使用。
面试官：Redis的数据淘汰策略有哪些 ?
候选人：
嗯，这个在redis中提供了很多种，默认是noeviction，不删除任何数据，内部不足直接报错。是可以在redis的配置文件中进行设置的，里面有两个非常重要的概念，一个是LRU，另外一个是LFU
LRU的意思就是最少最近使用，用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
LFU的意思是最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。我们在项目设置的allkeys-lru，挑选最近最少使用的数据淘汰，把一些经常访问的key留在redis中
面试官：数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的数据都是热点数据 ?
候选人：
嗯，我想一下，可以使用 allkeys-lru （挑选最近最少使用的数据淘汰）淘汰策略，那留下来的都是经常访问的热点数据
面试官：Redis的内存用完了会发生什么？
候选人：嗯，这个要看redis的数据淘汰策略是什么，如果是默认的配置，redis内存用完以后则直接报错。我们当时设置的 allkeys-lru 策略。把最近最常访问的数据留在缓存中。
面试官：Redis分布式锁如何实现 ?
候选人：嗯，在redis中提供了一个命令setnx(SET if not exists)。由于redis的单线程的，用了命令之后，只能有一个客户端对某一个key设置值，在没有过期或删除key的时候是其他客户端是不能设置这个key的
面试官：好的，那你如何控制Redis实现分布式锁有效时长呢？
候选人：嗯，的确，redis的setnx指令不好控制这个问题，我们当时采用的redis的一个框架redisson实现的。在redisson中需要手动加锁，并且可以控制锁的失效时间和等待时间，当锁住的一个业务还没有执行完成的时候，在redisson中引入了一个看门狗机制，就是说每隔一段时间就检查当前业务是否还持有锁，如果持有就增加加锁的持有时间，当业务执行完成之后需要使用释放锁就可以了。还有一个好处就是，在高并发下，一个业务有可能会执行很快，先客户1持有锁的时候，客户2来了以后并不会马上拒绝，它会自旋不断尝试获取锁，如果客户1释放之后，客户2就可以马上持有锁，性能也得到了提升。
面试官：好的，redisson实现的分布式锁是可重入的吗？
候选人：嗯，是可以重入的。这样做是为了避免死锁的产生。这个重入其实在内部就是判断是否是当前线程持有的锁，如果是当前线程持有的锁就会计数，如果释放锁就会在计算上减一。在存储数据的时候采用的hash结构，大key可以按照自己的业务进行定制，其中小key是当前线程的唯一标识，value是当前线程重入的次数
面试官：redisson实现的分布式锁能解决主从一致性的问题吗
候选人：这个是不能的，比如，当线程1加锁成功后，master节点数据会异步复制到slave节点，此时当前持有Redis锁的master节点宕机，slave节点被提升为新的master节点，假如现在来了一个线程2，再次加锁，会在新的master节点上加锁成功，这个时候就会出现两个节点同时持有一把锁的问
题。我们可以利用redisson提供的红锁来解决这个问题，它的主要作用是，不能只在一个redis实例上创建锁，应该是在多个redis实例上创建锁，并且要求在大多数redis节点上都成功创建锁，红锁中要求是redis的节点数量要过半。这样就能避免线程1加锁成功后master节点宕机导致线程2成功加锁到新的
master节点上的问题了。但是，如果使用了红锁，因为需要同时在多个节点上都添加锁，性能就变的很低了，并且运维维护成本也非常高，所以，我们一般在项目中也不会直接使用红锁，并且官方也暂时废弃了这个红锁
面试官：好的，如果业务非要保证数据的强一致性，这个该怎么解决呢？
候选人：嗯，redis本身就是支持高可用的，做到强一致性，就非常影响性能，所以，如果有强一致性要求高的业务，建议使用zookeeper实现的分布式锁，它是可以保证强一致性的。
面试官：Redis集群有哪些方案, 知道嘛 ?
候选人：嗯，在Redis中提供的集群方案总共有三种：主从复制、哨兵模式、Redis分片集群
面试官：那你来介绍一下主从同步
候选人：嗯，是这样的，单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，可以搭建主从集群，实现读写分离。一般都是一主多从，主节点负责写数据，从节点负责读数据，主节点写入数据之后，需要把数据同步到从节点中
面试官：能说一下，主从同步数据的流程
候选人：嗯，好！主从同步分为了两个阶段，一个是全量同步，一个是增量同步。全量同步是指从节点第一次与主节点建立连接的时候使用全量同步，流程是这样的：
第一：从节点请求主节点同步数据，其中从节点会携带自己的replication id和offset偏移量。
第二：主节点判断是否是第一次请求，主要判断的依据就是，主节点与从节点是否是同一个replication id，如果不是，就说明是第一次同步，那主节点就会把自己的replication id和offset发送给从节点，让从节点与主节点的信息保持一致。
第三：在同时主节点会执行bgsave，生成rdb文件后，发送给从节点去执行，从节点先把自己的数据清空，然后执行主节点发送过来的rdb文件，这样就保持了一致。
当然，如果在rdb生成执行期间，依然有请求到了主节点，而主节点会以命令的方式记录到缓冲区，缓冲区是一个日志文件，最后把这个日志文件发送给从节点，这样就能保证主节点与从节点完全一致了，后期再同步数据的时候，都是依赖于这个日志文件，这个就是全量同步增量同步指的是，当从节点服务重启之后，数据就不一致了，所以这个时候，从节点会请求主节点同步数据，主节点还是判断不是第一次请求，不是第一次就获取从节点的offset值，然后主节点从命令日志中获取offset值之后
的数据，发送给从节点进行数据同步
面试官：怎么保证Redis的高并发高可用
候选人：首先可以搭建主从集群，再加上使用redis中的哨兵模式，哨兵模式可以实现主从集群的自动故障恢复，里面就包含了对主从服务的监控、自动故障恢复、通知；如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主；同时Sentinel也充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端，所以一般项目都会采用哨兵的模式来保证redis的高并发高可用
面试官：你们使用redis是单点还是集群，哪种集群
候选人：嗯！，我们当时使用的是主从（1主1从）加哨兵。一般单节点不超过10G内存，如果Redis内存不足则可以给不同服务分配独立的Redis主从节点。尽量不做分片集群。因为集群维护起来比较麻烦，并且集群之间的心跳检测和数据通信会消耗大量的网络带宽，也没有办法使用lua脚本和事务
面试官：redis集群脑裂，该怎么解决呢？
候选人：嗯！ 这个在项目很少见，不过脑裂的问题是这样的，我们现在用的是redis的哨兵模式集群的
有的时候由于网络等原因可能会出现脑裂的情况，就是说，由于redis master节点和redis salve节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到master，所以通过选举的方式提升了一个salve为master，这样就存在了两个master，就像大脑分裂了一样，这样会导致客户端还在old master那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将old master降为salve，这时再从新master同步数据，这会导致old master中的大量数据丢失。关于解决的话，我记得在redis的配置中可以设置：第一可以设置最少的salve节点个数，比如设置至少要有一个从节点才能同步数据，第二个可以设置主从数据复制和同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的数据丢失
面试官：redis的分片集群有什么作用
候选人：分片集群主要解决的是，海量数据存储的问题，集群中有多个master，每个master保存不同数据，并且还可以给每个master设置多个slave节点，就可以继续增大集群的高并发能力。同时每个master之间通过ping监测彼此健康状态，就类似于哨兵模式了。当客户端请求可以访问集群任意节
点，最终都会被转发到正确节点
面试官：Redis分片集群中数据是怎么存储和读取的？
候选人：
嗯~，在redis集群中是这样的。Redis 集群引入了哈希槽的概念，有 16384 个哈希槽，集群中每个主节点绑定了一定范围的哈希槽范围， key通过 CRC16 校验后对 16384 取模来决定放置哪个槽，通过槽找到对应的节点进行存储。取值的逻辑是一样的
面试官：Redis是单线程的，但是为什么还那么快？
候选人：
嗯，这个有几个原因吧
1、完全基于内存的，C语言编写
2、采用单线程，避免不必要的上下文切换可竞争条件
3、使用多路I/O复用模型，非阻塞IO
例如：bgsave 和 bgrewriteaof 都是在后台执行操作，不影响主线程的正常使用，不会产生阻塞
面试官：能解释一下I/O多路复用模型？
候选人：嗯，I/O多路复用是指利用单个线程来同时监听多个Socket ，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。目前的I/O多路复用都是采用的epoll模式实现，它会在通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间，不需要挨个遍历
Socket来判断是否就绪，提升了性能。其中Redis的网络模型就是使用I/O多路复用结合事件的处理器来应对多个Socket请求，比如，提供了连接应答处理器、命令回复处理器，命令请求处理器；
在Redis6.0之后，为了提升更好的性能，在命令回复处理器使用了多线程来处理回复事件，在命令请求处理器中，将命令的转换使用了多线程，增加命令转换速度，在命令执行的时候，依然是单线程

MySQL面试题

MySQL面试题-文稿
面试官：MySQL中，如何定位慢查询?
候选人：
嗯~，我们当时做压测的时候有的接口非常的慢，接口的响应时间超过了2秒以上，因为我们当时的系统部署了运维的监控系统Skywalking ，在展示的报表中可以看到是哪一个接口比较慢，并且可以分析这个接口哪部分比较慢，这里可以看到SQL的具体的执行时间，所以可以定位是哪个sql出了问题。如果，项目中没有这种运维的监控系统，其实在MySQL中也提供了慢日志查询的功能，可以在MySQL的系统配置文件中开启这个慢日志的功能，并且也可以设置SQL执行超过多少时间来记录到一个日志文件中，我记得上一个项目配置的是2秒，只要SQL执行的时间超过了2秒就会记录到日志文件中，我
们就可以在日志文件找到执行比较慢的SQL了。
面试官：那这个SQL语句执行很慢, 如何分析呢？
候选人：如果一条sql执行很慢的话，我们通常会使用mysql自动的执行计划explain来去查看这条sql的执行情况，比如在这里面可以通过key和key_len检查是否命中了索引，如果本身已经添加了索引，也可以判断索引是否有失效的情况，第二个，可以通过type字段查看sql是否有进一步的优化空间，是否
存在全索引扫描或全盘扫描，第三个可以通过extra建议来判断，是否出现了回表的情况，如果出现了，可以尝试添加索引或修改返回字段来修复
面试官：了解过索引吗？（什么是索引）
候选人：嗯，索引在项目中还是比较常见的，它是帮助MySQL高效获取数据的数据结构，主要是用来提高数据检索的效率，降低数据库的IO成本，同时通过索引列对数据进行排序，降低数据排序的成本，也能降低了CPU的消耗
面试官：索引的底层数据结构了解过嘛 ?
候选人：MySQL的默认的存储引擎InnoDB采用的B+树的数据结构来存储索引，选择B+树的主要的原因是：第一阶数更多，路径更短，第二个磁盘读写代价B+树更低，非叶子节点只存储指针，叶子阶段存储数据，第三是B+树便于扫库和区间查询，叶子节点是一个双向链表
面试官：B树和B+树的区别是什么呢？
候选人：第一：在B树中，非叶子节点和叶子节点都会存放数据，而B+树的所有的数据都会出现在叶子节点，在查询的时候，B+树查找效率更加稳定。第二：在进行范围查询的时候，B+树效率更高，因为B+树都在叶子节点存储，并且叶子节点是一个双向链表
面试官：什么是聚簇索引什么是非聚簇索引 ?
候选人：
好的~，聚簇索引主要是指数据与索引放到一块，B+树的叶子节点保存了整行数据，有且只有一个，一般情况下主键在作为聚簇索引的非聚簇索引值的是数据与索引分开存储，B+树的叶子节点保存对应的主键，可以有多个，一般我们自己定义的索引都是非聚簇索引
面试官：知道什么是回表查询嘛 ?
候选人：嗯，其实跟刚才介绍的聚簇索引和非聚簇索引是有关系的，回表的意思就是通过二级索引找到对应的主键值，然后再通过主键值找到聚集索引中所对应的整行数据，这个过程就是回表
【备注：如果面试官直接问回表，则需要先介绍聚簇索引和非聚簇索引】
面试官：知道什么叫覆盖索引嘛 ?
候选人：嗯~，清楚的。覆盖索引是指select查询语句使用了索引，在返回的列，必须在索引中全部
能够找到，如果我们使用id查询，它会直接走聚集索引查询，一次索引扫描，直接返回数据，性能高。如果按照二级索引查询数据的时候，返回的列中没有创建索引，有可能会触发回表查询，尽量避免使用select *，尽量在返回的列中都包含添加索引的字段
面试官：MYSQL超大分页怎么处理 ?
候选人：嗯，超大分页一般都是在数据量比较大时，我们使用了limit分页查询，并且需要对数据进行排序，这个时候效率就很低，我们可以采用覆盖索引和子查询来解决。先分页查询数据的id字段，确定了id之后，再用子查询来过滤，只查询这个id列表中的数据就可以了因为查询id的时候，走的覆盖索引，所以效率可以提升很多
面试官：索引创建原则有哪些？
候选人：嗯，这个情况有很多，不过都有一个大前提，就是表中的数据要超过10万以上，我们才会创建索引，并且添加索引的字段是查询比较频繁的字段，一般也是像作为查询条件，排序字段或分组的字段这些。还有就是，我们通常创建索引的时候都是使用复合索引来创建，一条sql的返回值，尽量使用覆盖索引，如果字段的区分度不高的话，我们也会把它放在组合索引后面的字段。如果某一个字段的内容较长，我们会考虑使用前缀索引来使用，当然并不是所有的字段都要添加索引，这个索引的数量也要控制，因为添加索引也会导致新增改的速度变慢。
面试官：什么情况下索引会失效 ?
候选人：嗯，这个情况比较多，我说一些自己的经验，以前遇到过的比如，索引在使用的时候没有遵循最左匹配法则，第二个是，模糊查询，如果%号在前面也会导致索引失效。如果在添加索引的字段上进行了运算操作或者类型转换也都会导致索引失效。
我们之前还遇到过一个就是，如果使用了复合索引，中间使用了范围查询，右边的条件索引也会失效
所以，通常情况下，想要判断出这条sql是否有索引失效的情况，可以使用explain执行计划来分析
面试官：sql的优化的经验
候选人：嗯，这个在项目还是挺常见的，当然如果直说sql优化的话，我们会从这几方面考虑，比如
建表的时候、使用索引、sql语句的编写、主从复制，读写分离，还有一个是如果量比较大的话，可以考虑分库分表
面试官：创建表的时候，你们是如何优化的呢？
候选人：这个我们主要参考的阿里出的那个开发手册《嵩山版》，就比如，在定义字段的时候需要结合字段的内容来选择合适的类型，如果是数值的话，像tinyint、int 、bigint这些类型，要根据实际情况选择。如果是字符串类型，也是结合存储的内容来选择char和varchar或者text类型
面试官：那在使用索引的时候，是如何优化呢？
候选人：【参考索引创建原则 进行描述】
面试官：你平时对sql语句做了哪些优化呢？
候选人：嗯，这个也有很多，比如SELECT语句务必指明字段名称，不要直接使用select * ，还有就是要注意SQL语句避免造成索引失效的写法；如果是聚合查询，尽量用union all代替union ，union会多一次过滤，效率比较低；如果是表关联的话，尽量使用innerjoin ，不要使用用left join right join，如
必须使用 一定要以小表为驱动
面试官：事务的特性是什么？可以详细说一下吗？
候选人：嗯，这个比较清楚，ACID，分别指的是：原子性、一致性、隔离性、持久性；我举个例子：
A向B转账500，转账成功，A扣除500元，B增加500元，原子操作体现在要么都成功，要么都失败
在转账的过程中，数据要一致，A扣除了500，B必须增加500
在转账的过程中，隔离性体现在A像B转账，不能受其他事务干扰
在转账的过程中，持久性体现在事务提交后，要把数据持久化（可以说是落盘操作）
面试官：并发事务带来哪些问题？
候选人：
我们在项目开发中，多个事务并发进行是经常发生的，并发也是必然的，有可能导致一些问题.第一是脏读， 当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。第二是不可重复读：比如在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。第三是幻读（Phantom read）：幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。
面试官：怎么解决这些问题呢？MySQL的默认隔离级别是？
候选人：解决方案是对事务进行隔离
MySQL支持四种隔离级别，分别有：第一个是，未提交读（read uncommitted）它解决不了刚才提出的所有问题，一般项目中也不用这个。第二个是读已提交（read committed）它能解决脏读的问题的，但是解决不了不可重复读和幻读。第三个是可重复读（repeatable read）它能解决脏读和不可重复读，但是解决不了幻读，这个也是mysql默认的隔离级别。第四个是串行化（serializable）它可以解决刚才提出来的所有问题，但是由于让是事务串行执行的，性能比较低。所以，我们一般使用的都是mysql默认的隔离级别:可重复读
面试官：undo log和redo log的区别
候选人：好的，其中redo log日志记录的是数据页的物理变化，服务宕机可用来同步数据，而undo log 不同，它主要记录的是逻辑日志，当事务回滚时，通过逆操作恢复原来的数据，比如我们删除一条数据的时候，就会在undo log日志文件中新增一条delete语句，如果发生回滚就执行逆操作；redo log保证了事务的持久性，undo log保证了事务的原子性和一致性
面试官：事务中的隔离性是如何保证的呢？(你解释一下MVCC)
候选人：事务的隔离性是由锁和mvcc实现的。其中mvcc的意思是多版本并发控制。指维护一个数据的多个版本，使得读写操作没有冲突，它的底层实现主要是分为了三个部分，第一个是隐藏字段，
第二个是undo log日志，第三个是readView读视图。隐藏字段是指：在mysql中给每个表都设置了隐藏字段，有一个是trx_id(事务id)，记录每一次操作的事务id，是自增的；另一个字段是roll_pointer(回
滚指针)，指向上一个版本的事务版本记录地址。undo log主要的作用是记录回滚日志，存储老版本数据，在内部会形成一个版本链，在多个事务并行操作某一行记录，记录不同事务修改数据的版本，
通过roll_pointer指针形成一个链表。readView解决的是一个事务查询选择版本的问题，在内部定义了一些匹配规则和当前的一些事务id判断该访问那个版本的数据，不同的隔离级别快照读是不一样的，最终的访问的结果不一样。如果是rc隔离级别，每一次执行快照读时生成ReadView，如果是rr隔离级别仅在事务中第一次执行快照读时生成ReadView，后续复用
面试官：MySQL主从同步原理
候选人：MySQL主从复制的核心就是二进制日志(DDL（数据定义语言）语句和 DML（数据操纵语言）语句)，它的步骤是这样的：
第一：主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。
第二：从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志Relay Log 。
第三：从库重做中继日志中的事件，将改变反映它自己的数据
面试官：你们项目用过MySQL的分库分表吗？
候选人：
嗯，因为我们都是微服务开发，每个微服务对应了一个数据库，是根据业务进行拆分的，这个其实就是垂直拆分。
面试官：那你之前使用过水平分库吗？
候选人：
嗯，这个是使用过的，我们当时的业务是(xxx)，一开始，我们也是单库，后来这个业务逐渐发展，业务量上来的很迅速，其中(xx)表已经存放了超过1000万的数据，我们做了很多优化也不好使，性能依然很慢，所以当时就使用了水平分库。我们一开始先做了3台服务器对应了3个数据库，由于库多了，需要分片，我们当时采用的mycat来作为数据库的中间件。数据都是按照id（自增）取模的方式来存取的。当然一开始的时候，那些旧数据，我们做了一些清洗的工作，我们也是按照id取模规则分别存储到了各个数据库中，好处就是可以让各个数据库分摊存储和读取的压力，解决了我们当时性能的问题

框架篇面试题-参考回答

框架篇面试题-参考回答
面试官：Spring框架中的单例bean是线程安全的吗？
候选人：
嗯！不是线程安全的，是这样的。当多用户同时请求一个服务时，容器会给每一个请求分配一个线程，这是多个线程会并发执行该请求对应的业务逻辑（成员方法），如果该处理逻辑中有对该单列状态的修改（体现为该单例的成员属性），则必须考虑线程同步问题。
Spring框架并没有对单例bean进行任何多线程的封装处理。关于单例bean的线程安全和并发问题需要开发者自行去搞定。
比如：我们通常在项目中使用的Spring bean都是不可可变的状态(比如Service类和DAO类)，所以在某种程度上说Spring的单例bean是线程安全的。如果你的bean有多种状态的话（比如 View Model对象），就需要自行保证线程安全。最浅显的解决办法就是将多态bean的作用由“singleton”变更为“prototype”。
面试官：什么是AOP
候选人：
aop是面向切面编程，在spring中用于将那些与业务无关，但却对多个对象产生影响的公共行为和逻辑，抽取公共模块复用，降低耦合，一般比如可以做为公共日志保存，事务处理等
面试官：你们项目中有没有使用到AOP
候选人：我们当时在后台管理系统中，就是使用aop来记录了系统的操作日志主要思路是这样的，使用aop中的环绕通知+切点表达式，这个表达式就是要找到要记录日志的方法，然后通过环绕通知的参数获取请求方法的参数，比如类信息、方法信息、注解、请求方式等，获取到这些参数以后，保存到数据库
面试官：Spring中的事务是如何实现的
候选人：
spring实现的事务本质就是aop完成，对方法前后进行拦截，在执行方法之前开启事务，在执行完目标方法之后根据执行情况提交或者回滚事务。
面试官：Spring中事务失效的场景有哪些
候选人：
嗯！这个在项目中之前遇到过，我想想啊。第一个，如果方法上异常捕获处理，自己处理了异常，没有抛出，就会导致事务失效，所以一般处理了异常以后，别忘了跑出去就行了。第二个，如果方法抛出检查异常，如果报错也会导致事务失效，最后在
spring事务的注解上，就是@Transactional上配置rollbackFor属性为Exception，这样别管是什么异常，都会回滚事务
第三，我之前还遇到过一个，如果方法上不是public修饰的，也会导致事务失效。嗯，就能想起来那么多
面试官：Spring的bean的生命周期
候选人：
嗯！，这个步骤还是挺多的，我之前看过一些源码，它大概流程是这样的首先会通过一个非常重要的类，叫做BeanDefinition获取bean的定义信息，这里面就封装了bean的所有信息，比如，类的全路径，是否是延迟加载，是否是单例等等这些信息。在创建bean的时候，第一步是调用构造函数实例化bean。第二步是bean的依赖注入，比如一些set方法注入，像平时开发用的
@Autowire都是这一步完成。第三步是处理Aware接口，如果某一个bean实现了Aware接口就会重写方法执行。第四步是bean的后置处理器BeanPostProcessor，这个是前置处理器。第五步是初始化方法，比如实现了接口InitializingBean或者自定义了方法
init-method标签或@PostContruct。第六步是执行了bean的后置处理器BeanPostProcessor，主要是对bean进行增强，有可能在这里产生代理对象。最后一步是销毁bean
面试官：Spring中的循环引用
候选人：
嗯，好的，我来解释一下。循环依赖：循环依赖其实就是循环引用,也就是两个或两个以上的bean互相持有对方,最终形成闭环。比如A依赖于B,B依赖于A循环依赖在spring中是允许存在，spring框架依据三级缓存已经解决了大部分的循环依赖
①一级缓存：单例池，缓存已经经历了完整的生命周期，已经初始化完成的bean对象
②二级缓存：缓存早期的bean对象（生命周期还没走完）
③三级缓存：缓存的是ObjectFactory，表示对象工厂，用来创建某个对象的
面试官：那具体解决流程清楚吗？
候选人：
第一，先实例A对象，同时会创建ObjectFactory对象存入三级缓存singletonFactories
第二，A在初始化的时候需要B对象，这个走B的创建的逻辑
第三，B实例化完成，也会创建ObjectFactory对象存入三级缓存singletonFactories
第四，B需要注入A，通过三级缓存中获取ObjectFactory来生成一个A的对象，同时存入二级缓存，这个是有两种情况，一个是可能是A的普通对象，另外一个是A的代理对象，都可以让ObjectFactory来生产对应的对象，这也是三级缓存的关键
第五，B通过从通过二级缓存earlySingletonObjects 获得到A的对象后可以正常注入，B创建成功，存入一级缓存singletonObjects
第六，回到A对象初始化，因为B对象已经创建完成，则可以直接注入B，A创建成功存入一次缓存singletonObjects
第七，二级缓存中的临时对象A清除
面试官：构造方法出现了循环依赖怎么解决？
候选人：由于bean的生命周期中构造函数是第一个执行的，spring框架并不能解决构造函数的的依赖注入，可以使用@Lazy懒加载，什么时候需要对象再进行bean对象的创建
面试官：SpringMVC的执行流程知道嘛
候选人：
嗯，这个知道的，它分了好多步骤
1、用户发送出请求到前端控制器DispatcherServlet，这是一个调度中心
2、DispatcherServlet收到请求调用HandlerMapping（处理器映射器）。
3、HandlerMapping找到具体的处理器(可查找xml配置或注解配置)，生成处理器对象及处理器拦截器(如果有)，再一起返回给DispatcherServlet。
4、DispatcherServlet调用HandlerAdapter（处理器适配器）。
5、HandlerAdapter经过适配调用具体的处理器（Handler/Controller）。
6、Controller执行完成返回ModelAndView对象。
7、HandlerAdapter将Controller执行结果ModelAndView返回给DispatcherServlet。
8、DispatcherServlet将ModelAndView传给ViewReslover（视图解析器）。
9、ViewReslover解析后返回具体View（视图）。
10、DispatcherServlet根据View进行渲染视图（即将模型数据填充至视图
中）。
11、DispatcherServlet响应用户。
当然现在的开发，基本都是前后端分离的开发的，并没有视图这些，一般都是handler中使用Response直接结果返回
面试官：Springboot自动配置原理
候选人：
嗯，好的，它是这样的。在Spring Boot项目中的引导类上有一个注解@SpringBootApplication，这个注解是对三个注解进行了封装，分别是：
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan
其中 @EnableAutoConfiguration 是实现自动化配置的核心注解。该注解通过 @Import 注解导入对应的配置选择器。关键的是内部就是读取了。该项目和该项目引用的Jar包的的classpath路径下METAINF/spring.factories文件中的所配置的类的全类名。
在这些配置类中所定义的Bean会根据条件注解所指定的条件来决定是否需要将其导入到Spring容器中。一般条件判断会有像 @ConditionalOnClass 这样的注解，判断是否有对应的class文件，如果有则加载该类，把这个配置类的所有的Bean放入spring容器中使用。
面试官：Spring 的常见注解有哪些？
候选人：
嗯，这个就很多了
第一类是：声明bean，有@Component、@Service、@Repository、@Controller
第二类是：依赖注入相关的，有@Autowired、@Qualifier、@Resourse
第三类是：设置作用域 @Scope
第四类是：spring配置相关的，比如@Configuration，@ComponentScan 和@Bean
第五类是：跟aop相关做增强的注解 @Aspect，@Before，@After，@Around，@Pointcut
面试官：SpringMVC常见的注解有哪些？
候选人：
嗯，这个也很多的有@RequestMapping：用于映射请求路径；@RequestBody：注解实现接收http请求的json数据，将json转换为java对象；@RequestParam：指定请求参数的名称；@PathViriable：从请求路径下中获取请求参数(/user/{id})，传递给方法的
形式参数；@ResponseBody：注解实现将controller方法返回对象转化为json对象响应给客户端。@RequestHeader：获取指定的请求头数据，还有像@PostMapping、@GetMapping这些。
面试官：Springboot常见注解有哪些？
候选人：
嗯。Spring Boot的核心注解是@SpringBootApplication , 他由几个注解组成 :@SpringBootConfiguration： 组合了- @Configuration注解，实现配置文件的功能；
@EnableAutoConfiguration：打开自动配置的功能，也可以关闭某个自动配置的选项
@ComponentScan：Spring组件扫描
面试官：MyBatis执行流程
候选人：好，这个知道的，不过步骤也很多
①读取MyBatis配置文件：mybatis-config.xml加载运行环境和映射文件
②构造会话工厂SqlSessionFactory，一个项目只需要一个，单例的，一般由spring进行管理
③会话工厂创建SqlSession对象，这里面就含了执行SQL语句的所有方法
④操作数据库的接口，Executor执行器，同时负责查询缓存的维护
⑤Executor接口的执行方法中有一个MappedStatement类型的参数，封装了映射信息
⑥输入参数映射
⑦输出结果映射
面试官：Mybatis是否支持延迟加载？
候选人：
是支持的~。延迟加载的意思是：就是在需要用到数据时才进行加载，不需要用到数据时就不加载数据。
Mybatis支持一对一关联对象和一对多关联集合对象的延迟加载。在Mybatis配置文件中，可以配置是否启用延迟加载
lazyLoadingEnabled=true|false，默认是关闭的
面试官：延迟加载的底层原理知道吗？
候选人：嗯，我想想啊
延迟加载在底层主要使用的CGLIB动态代理完成的。第一是，使用CGLIB创建目标对象的代理对象，这里的目标对象就是开启了
延迟加载的mapper。第二个是当调用目标方法时，进入拦截器invoke方法，发现目标方法是null值，再执行sql查询。第三个是获取数据以后，调用set方法设置属性值，再继续查询目标方法，就有值了
面试官：Mybatis的一级、二级缓存用过吗？
候选人：嗯，用过的~。mybatis的一级缓存: 基于 PerpetualCache 的 HashMap 本地缓存，其存储作用域为 Session，当Session进行flush或close之后，该Session中的所有Cache就将清空，默认打开一级缓存。关于二级缓存需要单独开启，二级缓存是基于namespace和mapper的作用域起作用的，不是依赖于SQLsession，默认也是采用 PerpetualCache，HashMap 存储。如果想要开启二级缓存需要在全局配置文件和映射文件中开启配置才行。
面试官：Mybatis的二级缓存什么时候会清理缓存中的数据
候选人：嗯！！当某一个作用域(一级缓存 Session/二级缓存Namespaces)的进行了新增、修改、删除操作后，默认该作用域下所有 select 中的缓存将被 clear。

微服务面试题

微服务面试题
面试官：Spring Cloud 5大组件有哪些？
候选人：
早期我们一般认为的Spring Cloud五大组件是：
Eureka : 注册中心
Ribbon : 负载均衡
Feign : 远程调用
Hystrix : 服务熔断
Zuul/Gateway : 网关
随着SpringCloudAlibba在国内兴起 , 我们项目中使用了一些阿里巴巴的组件
注册中心/配置中心 Nacos
负载均衡 Ribbon
服务调用 Feign
服务保护 sentinel
服务网关 Gateway
面试官：服务注册和发现是什么意思？Spring Cloud 如何实现服务注册发现？
候选人：
我理解的是主要三块大功能，分别是服务注册 、服务发现、服务状态监控。我们当时项目采用eureka作为注册中心，这个也是spring cloud体系中的一个核心组件
服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除
面试官：我看你之前也用过nacos、你能说下nacos与eureka的区别？
候选人：我们当时xx项目就是采用的nacos作为注册中心，选择nacos还要一个重要原因就是它支持配置中心，不过nacos作为注册中心，也比eureka要方便好用一些，主要相同不同点在于几点：
共同点
Nacos与eureka都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
①Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
②临时实例心跳不正常会被剔除，非临时实例则不会被剔除
③Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
④Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
面试官：你们项目负载均衡如何实现的 ?
候选人：
是这样
在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon 组件实现 ,Feign的底层已经自动集成了Ribbon , 使用起来非常简单。当发起远程调用时，ribbon先从注册中心拉取服务地址列表，然后按照一定的路由策略选择一个发起远程调用，一般的调用策略是轮询
面试官：Ribbon负载均衡策略有哪些 ?
候选人：
我想想啊，有很多种，我记得几个：
RoundRobinRule：简单轮询服务列表来选择服务器
WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小
RandomRule：随机选择一个可用的服务器
ZoneAvoidanceRule：区域敏感策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)
面试官：如果想自定义负载均衡策略如何实现 ?
候选人：
提供了两种方式：
1，创建类实现IRule接口，可以指定负载均衡策略，这个是全局的，对所有的远程调用都起作用
2，在客户端的配置文件中，可以配置某一个服务调用的负载均衡策略，只是对配置的这个服务生效远程调用
面试官：什么是服务雪崩，怎么解决这个问题？
候选人：
服务雪崩是指一个服务失败，导致整条链路的服务都失败的情形，一般我们在项目解决的话就是两种方案，第一个是服务降级，第二个是服务熔断，如果流量太大的话，可以考虑限流
服务降级：服务自我保护的一种方式，或者保护下游服务的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃，一般在实际开发中与feign接口整合，编写降级逻辑
服务熔断：默认关闭，需要手动打开，如果检测到 10 秒内请求的失败率超过 50%，就触发熔断机制。之后每隔 5 秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求
面试官：你们的微服务是怎么监控的？
候选人：
我们项目中采用的skywalking进行监控的
1，skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。
2，我们还在skywalking设置了告警规则，特别是在项目上线以后，如果报错，我们分别设置了可以给相关负责人发短信和发邮件，第一时间知道项目的bug情况，第一时间修复
面试官：你们项目中有没有做过限流 ? 怎么做的 ?
候选人：
我当时做的xx项目，采用就是微服务的架构，因为xx因为，应该会有突发流量，最大QPS可以达到2000，但是服务支撑不住，我们项目都通过压测最多可以支撑1200QPS。因为我们平时的QPS也就不到100，为了解决这些突发流量，所以采用了限流。
【版本1】
我们当时采用的nginx限流操作，nginx使用的漏桶算法来实现过滤，让请求以固定的速率处理请求，可以应对突发流量，我们控制的速率是按照ip进行限流，限制的流量是每秒20
【版本2】
我们当时采用的是spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流，使用的是令牌桶算法，可以根据ip或路径进行限流，可以设置每秒填充平均速率，和令牌桶总容量
面试官：限流常见的算法有哪些呢？
候选人：
比较常见的限流算法有漏桶算法和令牌桶算法。漏桶算法是把请求存入到桶中，以固定速率从桶中流出，可以让我们的服务做到绝对的平均，起到很好的限流效果。令牌桶算法在桶中存储的是令牌，按照一定的速率生成令牌，每个请求都要先申请令牌，申请到令牌以后才能正常请求，也可以起到很好的限流作用。它们的区别是，漏桶和令牌桶都可以处理突发流量，其中漏桶可以做到绝对的平滑，令牌桶有可能会产生突发大量请求的情况，一般nginx限流采用的漏桶，spring cloud gateway中可以支持令牌桶算法
面试官：什么是CAP理论？
候选人：
CAP主要是在分布式项目下的一个理论。包含了三项，一致性、可用性、分区容错性
一致性(Consistency)是指更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致(强一致性)，不能存在中间状态。
可用性(Availability) 是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容错性(Partition tolerance) 是指分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
面试官：为什么分布式系统中无法同时保证一致性和可用性？
候选人：
嗯，是这样的。首先一个前提，对于分布式系统而言，分区容错性是一个最基本的要求，因此基本上我们在设计分布式系统的时候只能从一致性（C）和可用性（A）之间进行取舍。
如果保证了一致性（C）：对于节点N1和N2，当往N1里写数据时，N2上的操作必须被暂停，只有当N1同步数据到N2时才能对N2进行读写请求，在N2被暂停操作期间客户端提交的请求会收到失败或超时。显然，这与可用性是相悖的。
如果保证了可用性（A）：那就不能暂停N2的读写操作，但同时N1在写数据的话，这就违背了一致性的要求。
面试官：什么是BASE理论？
候选人：
嗯，这个也是CAP分布式系统设计理论。BASE是CAP理论中AP方案的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。它的思想包含三方面：
1、Basically Available（基本可用）：基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。
2、Soft state（软状态）：即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
3、Eventually consistent（最终一致性）：强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
面试官：你们采用哪种分布式事务解决方案？
候选人：
我们当时是xx项目，主要使用到的seata的at模式解决的分布式事务。seata的AT模型分为两个阶段：
1、阶段一RM的工作：① 注册分支事务 ② 记录undo-log（数据快照）③执行业务sql并提交 ④报告事务状态
2、阶段二提交时RM的工作：删除undo-log即可
3、阶段二回滚时RM的工作：根据undo-log恢复数据到更新前
at模式牺牲了一致性，保证了可用性，不过，它保证的是最终一致性
面试官：分布式服务的接口幂等性如何设计？
候选人：
嗯，我们当时有一个xx项目的下单操作，采用的token+redis实现的，流程是这样的。第一次请求，也就是用户打开了商品详情页面，我们会发起一个请求，在后台生成一个唯一token存入redis，key就是用户的id，value就是这个token，同时把这个token返回前端
第二次请求，当用户点击了下单操作会后，会携带之前的token，后台先到redis进行验证，如果存在token，可以执行业务，同时删除token；如果不存在，则直接返回，不处理业务，就保证了同一个token只处理一次业务，就保证了幂等性
面试官：xxl-job路由策略有哪些？
候选人：
xxl-job提供了很多的路由策略，我们平时用的较多就是：轮询、故障转移、分片广播…
面试官：xxl-job任务执行失败怎么解决？
候选人：
有这么几个操作
第一：路由策略选择故障转移，优先使用健康的实例来执行任务
第二，如果还有失败的，我们在创建任务时，可以设置重试次数
第三，如果还有失败的，就可以查看日志或者配置邮件告警来通知相关负责人解决
面试官：如果有大数据量的任务同时都需要执行，怎么解决？
候选人：
我们会让部署多个实例，共同去执行这些批量的任务，其中任务的路由策略是分片广播。在任务执行的代码中可以获取分片总数和当前分片，按照取模的方式分摊到各个实例执行就可以了

消息中间件面试题-参考回答

消息中间件面试题-参考回答
面试官：RabbitMQ-如何保证消息不丢失
候选人：
嗯！我们当时MYSQL和Redis的数据双写一致性就是采用RabbitMQ实现同步的，这里面就要求了消息的高可用性，我们要保证消息的不丢失。主要从三个层面考虑
第一个是开启生产者确认机制，确保生产者的消息能到达队列，如果报错可以先记录到日志中，再去修复数据
第二个是开启持久化功能，确保消息未消费前在队列中不会丢失，其中的交换机、队列、和消息都要做持久化
第三个是开启消费者确认机制为auto，由spring确认消息处理成功后完成ack，当然也需要设置一定的重试次数，我们当时设置了3次，如果重试3次还没有收到消息，就将失败后的消息投递到异常交换机，交由人工处理
面试官：RabbitMQ消息的重复消费问题如何解决的
候选人：
嗯，这个我们还真遇到过，是这样的，我们当时消费者是设置了自动确认机制，当服务还没来得及给MQ确认的时候，服务宕机了，导致服务重启之后，又消费了一次消息。这样就重复消费了。因为我们当时处理的支付（订单|业务唯一标识），它有一个业务的唯一标识，我们再处理消息时，先到数据库查询一下，这个数据是否存在，如果不存在，说明没有处理过，这个时候就可以正常处理这个消息了。如果已经存在这个数据了，就说明消息重复消费了，我们就不需要再消费了
面试官：那你还知道其他的解决方案吗？
候选人：
嗯，我想想~
其实这个就是典型的幂等的问题，比如，redis分布式锁、数据库的锁都是可以的
面试官：RabbitMQ中死信交换机 ? （RabbitMQ延迟队列有了解过嘛）
候选人：
嗯！了解过！我们当时的xx项目有一个xx业务，需要用到延迟队列，其中就是使用RabbitMQ来实现的。延迟队列就是用到了死信交换机和TTL（消息存活时间）实现的。如果消息超时未消费就会变成死信，在RabbitMQ中如果消息成为死信，队列可以绑定一个死信交换机，在死信交换机上可以绑定其他队列，在我们发消息的时候可以按照需求指定TTL的时间，这样就实现了延迟队列的功能了。
我记得RabbitMQ还有一种方式可以实现延迟队列，在RabbitMQ中安装一个死信插件，这样更方便一些，我们只需要在声明交互机的时候，指定这个就是死信交换机，然后在发送消息的时候直接指定超时时间就行了，相对于死信交换机+TTL要省略了一些步骤
面试官：如果有100万消息堆积在MQ , 如何解决 ?
候选人：
我在实际的开发中，没遇到过这种情况，不过，如果发生了堆积的问题，解决方案也所有很多的
第一:提高消费者的消费能力 ,可以使用多线程消费任务
第二：增加更多消费者，提高消费速度使用工作队列模式, 设置多个消费者消费消费同一个队列中的消息
第三：扩大队列容积，提高堆积上限
可以使用RabbitMQ惰性队列，惰性队列的好处主要是
①接收到消息后直接存入磁盘而非内存
②消费者要消费消息时才会从磁盘中读取并加载到内存
③支持数百万条的消息存储
面试官：RabbitMQ的高可用机制有了解过嘛
候选人：
嗯，熟悉的~我们当时项目在生产环境下，使用的集群，当时搭建是镜像模式集群，使用了3台机器。
镜像队列结构是一主多从，所有操作都是主节点完成，然后同步给镜像节点，如果主节点宕机后，镜像节点会替代成新的主节点，不过在主从同步完成前，主节点就已经宕机，可能出现数据丢失
面试官：那出现丢数据怎么解决呢？
候选人：
我们可以采用仲裁队列，与镜像队列一样，都是主从模式，支持主从数据同步，主从同步基于Raft协议，强一致。并且使用起来也非常简单，不需要额外的配置，在声明队列的时候只要指定这个是仲裁队列即可
面试官：Kafka是如何保证消息不丢失
候选人：
嗯，这个保证机制很多，在发送消息到消费者接收消息，在每个阶段都有可能会丢失消息，所以我们解决的话也是从多个方面考虑。第一个是生产者发送消息的时候，可以使用异步回调发送，如果消息发送失败，我们可以通过回调获取失败后的消息信息，可以考虑重试或记录日志，后边再做补偿都是可以的。同时在生产者这边还可以设置消息重试，有的时候是由于网络抖动的原因导致发送不成功，就可以使用重试机制来解决。第二个在broker中消息有可能会丢失，我们可以通过kafka的复制机制来确保消息不丢失，在生产者发送消息的时候，可以设置一个acks，就是确认机制。我们可以设置参数为all，这样的话，当生产者发送消息到了分区之后，不仅仅只在leader分区保存确认，在follwer分区也会保存确认，只有当所有的副本都保存确认以后才算是成功发送了消息，所以，这样设置就很大程度了保证了消息不会在broker丢失。第三个有可能是在消费者端丢失消息，kafka消费消息都是按照offset进行标记消费的，消费者默认是自动按期提交已经消费的偏移量，默认是每隔5s提交一次，如果出现重平衡的情况，可能会重复消费或丢失数据。我们一般都会禁用掉自动提价偏移量，改为手动提交，当消费成功以后再报告给broker消费的位置，这样就可以避免消息丢失和重复消费了
面试官：Kafka中消息的重复消费问题如何解决的
候选人：
kafka消费消息都是按照offset进行标记消费的，消费者默认是自动按期提交已经消费的偏移量，默认是每隔5s提交一次，如果出现重平衡的情况，可能会重复消费或丢失数据。我们一般都会禁用掉自动提价偏移量，改为手动提交，当消费成功以后再报告给broker消费的位置，这样就可以避免消息丢失
和重复消费了。为了消息的幂等，我们也可以设置唯一主键来进行区分，或者是加锁，数据库的锁，或者是redis分布式锁，都能解决幂等的问题
面试官：Kafka是如何保证消费的顺序性
候选人：
kafka默认存储和消费消息，是不能保证顺序性的，因为一个topic数据可能存储在不同的分区中，每个分区都有一个按照顺序的存储的偏移量，如果消费者关联了多个分区不能保证顺序性。如果有这样的需求的话，我们是可以解决的，把消息都存储同一个分区下就行了，有两种方式都可以进行设置，第一个是发送消息时指定分区号，第二个是发送消息时按照相同的业务设置相同的key，因为默认情况下分区也是通过key的hashcode值来选择分区的，hash值如果一样的话，分区肯定也是一样的
面试官：Kafka的高可用机制有了解过嘛
候选人：
嗯，主要是有两个层面，第一个是集群，第二个是提供了复制机制。kafka集群指的是由多个broker实例组成，即使某一台宕机，也不耽误其他broker继续对外提供服务复制机制是可以保证kafka的高可用的，一个topic有多个分区，每个分区有多个副本，有一个leader，其余的是follower，副本存储在不同的broker中；所有的分区副本的内容是都是相同的，如果leader发生故障时，会自动将其中一个follower提升为leader，保证了系统的容错性、高可用性
面试官：解释一下复制机制中的ISR
候选人：
ISR的意思是in-sync replica，就是需要同步复制保存的follower其中分区副本有很多的follower，分为了两类，一个是ISR，与leader副本同步保存数据，另外一个普通的副本，是异步同步数据，当leader挂掉之后，会优先从ISR副本列表中选取一个作为leader，因为ISR是同步保存数据，数据更加的完整一些，所以优先选择ISR副本列表
面试官：Kafka数据清理机制了解过嘛
候选人：
嗯，了解过~~Kafka中topic的数据存储在分区上，分区如果文件过大会分段存储segment每个分段都在磁盘上以索引(xxxx.index)和日志文件(xxxx.log)的形式存储，这样分段的好处是，第一能够减少单个文件内容的大小，查找数据方便，第二方便kafka进行日志清理。
在kafka中提供了两个日志的清理策略：
第一，根据消息的保留时间，当消息保存的时间超过了指定的时间，就会触发清理，默认是168小时（ 7天）
第二是根据topic存储的数据大小，当topic所占的日志文件大小大于一定的阈值，则开始删除最久的消息。这个默认是关闭的。这两个策略都可以通过kafka的broker中的配置文件进行设置
面试官：Kafka中实现高性能的设计有了解过嘛
候选人：
Kafka 高性能，是多方面协同的结果，包括宏观架构、分布式存储、ISR 数据同步、以及高效的利用磁盘、操作系统特性等。主要体现有这么几点：
消息分区：不受单台服务器的限制，可以不受限的处理更多的数据顺序读写：磁盘顺序读写，提升读写效率
页缓存：把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问零拷贝：减少上下文切换及数据拷贝
消息压缩：减少磁盘IO和网络IO
分批发送：将消息打包批量发送，减少网络开销

Java集合相关面试题

面试官：说一说Java提供的常见集合？（画一下集合结构图）
候选人：
嗯~~，好的。在java中提供了量大类的集合框架，主要分为两类：
第一个是Collection 属于单列集合，第二个是Map 属于双列集合在Collection中有两个子接口List和Set。在我们平常开发的过程中用的比较多像list接口中的实现类ArrarList和LinkedList。 在Set接口中有实现类HashSet和TreeSet。
在map接口中有很多的实现类，平时比较常见的是HashMap、TreeMap，还有一个线程安全的map:ConcurrentHashMap
面试官：ArrayList底层是如何实现的？
候选人：嗯~，我阅读过arraylist的源码，我主要说一下add方法吧。
第一：确保数组已使用长度（size）加1之后足够存下下一个数据
第二：计算数组的容量，如果当前数组已使用长度+1后的大于当前的数组长度，则调用grow方法扩容（原来的1.5倍）
第三：确保新增的数据有地方存储之后，则将新元素添加到位于size的位置上。
第四：返回添加成功布尔值。
面试官：ArrayList list=new ArrayList(10)中的list扩容几次
候选人：
是new了一个ArrarList并且给了一个构造参数10，对吧？(问题一定要问清楚再答)
面试官：是的
候选人：
好的，在ArrayList的源码中提供了一个带参数的构造方法，这个参数就是指定的集合初始长度，所以给了一个10的参数，就是指定了集合的初始长度是10，这里面并没有扩容。
面试官：如何实现数组和List之间的转换
候选人：
嗯，这个在我们平时开发很常见。 数组转list，可以使用jdk自动的一个工具类Arrars，里面有一个asList方法可以转换为数组 List 转数组，可以直接调用list中的toArray方法，需要给一个参数，指定数
组的类型，需要指定数组的长度。
面试官：用Arrays.asList转List后，如果修改了数组内容，list受影响吗？List用toArray转数组后，如果修改了List内容，数组受影响吗
候选人：
Arrays.asList转换list之后，如果修改了数组的内容，list会受影响，因为它的底层使用的Arrays类中的一个内部类ArrayList来构造的集合，在这个集合的构造器中，把我们传入的这个集合进行了包装而已，最终指向的都是同一个内存地址。list用了toArray转数组后，如果修改了list内容，数组不会影响，当调用了toArray以后，在底层是它是进行了数组的拷贝，跟原来的元素就没啥关系了，所以即使list修改了以后，数组也不受影响
面试官：ArrayList 和 LinkedList 的区别是什么？
候选人：
嗯，它们两个主要是底层使用的数据结构不一样，ArrayList 是动态数组，LinkedList 是双向链表，这也导致了它们很多不同的特点。
1，从操作数据效率来说
ArrayList按照下标查询的时间复杂度O(1)【内存是连续的，根据寻址公式】， LinkedList不支持下标查询查找（未知索引）： ArrayList需要遍历，链表也需要链表，时间复杂度都是O(n)
新增和删除
ArrayList尾部插入和删除，时间复杂度是O(1)；其他部分增删需要挪动数组，时间复杂度是O(n)
LinkedList头尾节点增删时间复杂度是O(1)，其他都需要遍历链表，时间复杂度是O(n)
2，从内存空间占用来说
ArrayList底层是数组，内存连续，节省内存。LinkedList 是双向链表需要存储数据，和两个指针，更占用内存
3，从线程安全来说，ArrayList和LinkedList都不是线程安全的
面试官：嗯，好的，刚才你说了ArrayList 和 LinkedList 不是线程安全的，你
们在项目中是如何解决这个的线程安全问题的？
候选人：
嗯，是这样的，主要有两种解决方案：
第一：我们使用这个集合，优先在方法内使用，定义为局部变量，这样的话，就不会出现线程安全问题。
第二：如果非要在成员变量中使用的话，可以使用线程安全的集合来替代ArrayList可以通过Collections 的 synchronizedList 方法将 ArrayList 转换成线程安全的容器后再使用。
LinkedList 换成ConcurrentLinkedQueue来使用。
面试官：说一下HashMap的实现原理？
候选人：
嗯。它主要分为了一下几个部分：
1，底层使用hash表数据结构，即数组+（链表 | 红黑树）
2，添加数据时，计算key的值确定元素在数组中的下标
key相同则替换
不同则存入链表或红黑树中
3，获取数据通过key的hash计算数组下标获取元素
面试官：HashMap的jdk1.7和jdk1.8有什么区别
候选人：
JDK1.8之前采用的拉链法，数组+链表
JDK1.8之后采用数组+链表+红黑树，链表长度大于8且数组长度大于64则会从链表
转化为红黑树
面试官：好的，你能说下HashMap的put方法的具体流程吗？
候选人：
嗯好的。1. 判断键值对数组table是否为空或为null，否则执行resize()进行扩容（初始化）2. 根据键值key计算hash值得到数组索引3. 判断table[i]==null，条件成立，直接新建节点添加4. 如果table[i]==null ,不成立 4.1 判断table[i]的首个元素是否和key一样，如果相同直接覆盖value 4.2 判断table[i] 是否为treeNode，即table[i] 是否是红黑树，如果是红黑树，则直接在树中插入键值对 4.3 遍历table[i]，链表的尾部插入数据，然后判断链表长度是否大于8，大于8的话把链表转换为红黑树，在红黑树中执行插入操 作，遍历过程中若发现key已经存在直接覆盖value。5. 插入成功后，判断实际存在的键值对数量size是否超多了最大容量threshold（数组长度 * 0.75），如果超过，进行扩容。
面试官：好的，刚才你多次介绍了hsahmap的扩容，能讲一讲HashMap的扩容机制吗？
候选人：
好的。在添加元素或初始化的时候需要调用resize方法进行扩容，第一次添加数据初始化数组长度为16，以后每次每次扩容都是达到了扩容阈值（数组长度 * 0.75）每次扩容的时候，都是扩容之前容量的2倍；扩容之后，会新创建一个数组，需要把老数组中的数据挪动到新的数组中没有hash冲突的节点，则直接使用 e.hash & (newCap - 1) 计算新数组的索引位置。如果是红黑树，走红黑树的添加。
如果是链表，则需要遍历链表，可能需要拆分链表，判断(e.hash & oldCap)是否为0，该元素的位置要么停留在原始位置，要么移动到原始位置+增加的数组大小这个位置上
面试官：好的，刚才你说的通过hash计算后找到数组的下标，是如何找到的呢，你了解hashMap的寻址算法吗？
候选人：
这个哈希方法首先计算出key的hashCode值，然后通过这个hash值右移16位后的二进制进行按位异或运算得到最后的hash值。在putValue的方法中，计算数组下标的时候使用hash值与数组长度取模得到
存储数据下标的位置，hashmap为了性能更好，并没有直接采用取模的方式，而是使用了数组长度-1 得到一个值，用这个值按位与运算hash值，最终得到数组的位置。
面试官：为何HashMap的数组长度一定是2的次幂？
候选人：
嗯，好的。hashmap这么设计主要有两个原因：
第一：
计算索引时效率更高：如果是 2 的 n 次幂可以使用位与运算代替取模
第二：
扩容时重新计算索引效率更高：在进行扩容是会进行判断 hash值按位与运算旧数组长租是否 == 0
如果等于0，则把元素留在原来位置 ，否则新位置是等于旧位置的下标+旧数组长度
面试官：好的，我看你对hashmap了解的挺深入的，你知道hashmap在1.7情况下的多线程死循环问题吗？
候选人：
嗯，知道的。是这样。jdk7的的数据结构是：数组+链表。在数组进行扩容的时候，因为链表是头插法，在进行数据迁移的过程中，有可能导致死循环。比如说，现在有两个线程。线程一：读取到当前的hashmap数据，数据中一个链表，在准备扩容时，线程二介入。线程二也读取hashmap，直接进行扩容。因为是头插法，链表的顺序会进行颠倒过来。比如原来的顺序是AB，扩容后的顺序是BA，线程二执行结束。当线程一再继续执行的时候就会出现死循环的问题。线程一先将A移入新的链表，再将B插入到链头，由于另外一个线程的原因，B的next指向了A，所以B->A->B,形成循环。当然，JDK 8 将扩容算法做了调整，不再将元素加入链表头（而是保持与扩容前一样的顺序），尾插法，就避免了jdk7中死循环的问题。
面试官：好的，hashmap是线程安全的吗？
候选人：不是线程安全的
面试官：那我们想要使用线程安全的map该怎么做呢？
候选人：我们可以采用ConcurrentHashMap进行使用，它是一个线程安全的HashMap
面试官：那你能聊一下ConcurrentHashMap的原理吗？
候选人：好的，请参考《多线程相关面试题》中的ConcurrentHashMap部分的讲解
面试官：HashSet与HashMap的区别？
候选人：嗯，是这样。
HashSet底层其实是用HashMap实现存储的, HashSet封装了一系列HashMap的方法. 依靠HashMap来存储元素值,(利用hashMap的key键进行存储), 而value值默认为Object对象. 所以HashSet也不允许出现重复值, 判断标准和HashMap判断标准相同, 两个元素的hashCode相等并且通过equals()方法返回true.
面试官：HashTable与HashMap的区别
候选人：
嗯，他们的主要区别是有几个吧
第一，数据结构不一样，hashtable是数组+链表，hashmap在1.8之后改为了数组+链表+红黑树
第二，hashtable存储数据的时候都不能为null，而hashmap是可以的
第三，hash算法不同，hashtable是用本地修饰的hashcode值，而hashmap经常了二次hash
第四，扩容方式不同，hashtable是当前容量翻倍+1，hashmap是当前容量翻倍
第五，hashtable是线程安全的，操作数据的时候加了锁synchronized，hashmap不是线程安全的，效率更高一些。在实际开中不建议使用HashTable，在多线程环境下可以使用ConcurrentHashMap类

JVM面试题

面试官：JVM由那些部分组成，运行流程是什么？
候选人:
嗯，好的。在JVM中共有四大部分，分别是ClassLoader（类加载器）、Runtime Data
Area（运行时数据区，内存分区）、Execution Engine（执行引擎）、Native Method Library（本地库接口）
它们的运行流程是：
第一，类加载器（ClassLoader）把Java代码转换为字节码
第二，运行时数据区（Runtime Data Area）把字节码加载到内存中，而字节码文件只是JVM的一套指令集规范，并不能直接交给底层系统去执行，而是有执行引擎运行
第三，执行引擎（Execution Engine）将字节码翻译为底层系统指令，再交由CPU执行去执行，此时需要调用其他语言的本地库接口（Native Method Library）来实现整个程序的功能。
面试官：好的，你能详细说一下 JVM 运行时数据区吗？
候选人:
嗯，好~运行时数据区包含了堆、方法区、栈、本地方法栈、程序计数器这几部分，每个功能作用不一样。堆解决的是对象实例存储的问题，垃圾回收器管理的主要区域。方法区可以认为是堆的一部分，用于存储已被虚拟机加载的信息，常量、静态变量、即时编译器编译后的代码。栈解决的是程序运行的问题，栈里面存的是栈帧，栈帧里面存的是局部变量表、操作数栈、动态链接、方法出口等信息。本地方法栈与栈功能相同，本地方法栈执行的是本地方法，一个Java调用非Java代码的接口。
程序计数器（PC寄存器）程序计数器中存放的是当前线程所执行的字节码的行数。JVM工作时就是通过改变这个计数器的值来选取下一个需要执行的字节码指令。
面试官：好的，你再详细介绍一下程序计数器的作用？
候选人:
嗯，是这样，java虚拟机对于多线程是通过线程轮流切换并且分配线程执行时间。在任何的一个时间点上，一个处理器只会处理执行一个线程，如果当前被执行的这个线程它所分配的执行时间用完了【挂起】。处理器会切换到另外的一个线程上来进行执行。并且这个线程的执行时间用完了，接着处理器就会又来执行被挂起的这个线程。这时候程序计数器就起到了关键作用，程序计数器在来回切换的线程中记录他上一次执行的行号，然后接着继续向下执行。
面试官：你能给我详细的介绍Java堆吗?
候选人:
好的~Java中的堆术语线程共享的区域。主要用来保存对象实例，数组等，当堆中没有内存空间可分配给实例，也无法再扩展时，则抛出OutOfMemoryError异常。
在JAVA 8中堆内会存在年轻代、老年代
1）Young区被划分为三部分，Eden区和两个大小严格相同的Survivor区，其中，Survivor区间中，某一时刻只有其中一个是被使用的，另外一个留做垃圾收集时复制对象用。在Eden区变满的时候， GC就会将存活的对象移到空闲的Survivor区间中，根据JVM的策略，在经过几次垃圾收集后，任然存
活于Survivor的对象将被移动到Tenured区间。
2）Tenured区主要保存生命周期长的对象，一般是一些老的对象，当一些对象在Young复制转移一定的次数以后，对象就会被转移到Tenured区。
面试官：能不能解释一下方法区？
候选人:
好的~与虚拟机栈类似。本地方法栈是为虚拟机执行本地方法时提供服务的。不需要进行GC。本地方法一般是由其他语言编写。
面试官：你听过直接内存吗？
候选人:嗯，它又叫做堆外内存，线程共享的区域，在 Java 8 之前有个永久代的概念，实际上指的是 HotSpot 虚拟机上的永久代，它用永久代实现了 JVM 规范定义的方法区功能，主要存储类的信息，常量，静态变量，即时编译器编译后代码等，这部分由于是在堆中实现的，受 GC 的管理，不过由于永久代有 -XX:MaxPermSize 的上限，所以如果大量动态生成类（将类信息放入永久代），很容易造成 OOM，有人说可以把永久代设置得足够大，但很难确定一个合适的大小，受类数量，常量数量的多少影响很大。所以在 Java 8 中就把方法区的实现移到了本地内存中的元空间中，这样方法区就不受 JVM 的控制了,也就不会进行 GC，也因此提升了性能。
面试官：什么是虚拟机栈
候选人:虚拟机栈是描述的是方法执行时的内存模型,是线程私有的，生命周期与线程相同,每个方法被执行的同时会创建栈桢。保存执行方法时的局部变量、动态连接信息、方法返回地址信息等等。方法开始执行的时候会进栈，方法执行完会出栈【相当于清空了数据】，所以这块区域不需要进行GC。
面试官：能说一下堆栈的区别是什么吗？
候选人:
嗯，好的，有这几个区别
第一，栈内存一般会用来存储局部变量和方法调用，但堆内存是用来存储Java对象和数组的的。堆会GC垃圾回收，而栈不会。
第二、栈内存是线程私有的，而堆内存是线程共有的。
第三、两者异常错误不同，但如果栈内存或者堆内存不足都会抛出异常。
栈空间不足：java.lang.StackOverFlowError。
堆空间不足：java.lang.OutOfMemoryError。
面试官：什么是类加载器，类加载器有哪些?
候选人:
嗯，是这样的。JVM只会运行二进制文件，而类加载器（ClassLoader）的主要作用就是将字
节码文件加载到JVM中，从而让Java程序能够启动起来。
常见的类加载器有4个
第一个是启动类加载器(BootStrap ClassLoader)：其是由C++编写实现。用于加载JAVA_HOME/jre/lib目录下的类库。
第二个是扩展类加载器(ExtClassLoader)：该类是ClassLoader的子类，主要加载JAVA_HOME/jre/lib/ext目录中的类库。
第三个是应用类加载器(AppClassLoader)：该类是ClassLoader的子类，主要用于加载classPath下的类，也就是加载开发者自己编写的Java类。
第四个是自定义类加载器：开发者自定义类继承ClassLoader，实现自定义类加载规则。
面试官：说一下类装载的执行过程？
候选人:
嗯，这个过程还是挺多的。类从加载到虚拟机中开始，直到卸载为止，它的整个生命周期包括了：加
载、验证、准备、解析、初始化、使用和卸载这7个阶段。其中，验证、准备和解析这三个部分统称为连接（linking）
1.加载：查找和导入class文件
2.验证：保证加载类的准确性
3.准备：为类变量分配内存并设置类变量初始值
4.解析：把类中的符号引用转换为直接引用
5.初始化：对类的静态变量，静态代码块执行初始化操作
6.使用：JVM 开始从入口方法开始执行用户的程序代码
7.卸载：当用户程序代码执行完毕后，JVM 便开始销毁创建的 Class 对象，最后负责运行的 JVM 也退出内存
面试官：什么是双亲委派模型？
候选人:
嗯，它是是这样的。如果一个类加载器收到了类加载的请求，它首先不会自己尝试加载这个类，而是把这请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传说到顶层的启动类加载器中，只有当父类加载器返回自己无法完成这个加载请求（它的搜索返回中没有找到所需的类）时，子类加载器才会尝试自己去加载
面试官：JVM为什么采用双亲委派机制
候选人:
主要有两个原因。第一、通过双亲委派机制可以避免某一个类被重复加载，当父类已经加载后
则无需重复加载，保证唯一性。
第二、为了安全，保证类库API不会被修改
面试官：简述Java垃圾回收机制？（GC是什么？为什么要GC）
候选人:嗯，是这样，为了让程序员更专注于代码的实现，而不用过多的考虑内存释放的问题，所以，在Java语言中，有了自动的垃圾回收机制，也就是我们熟悉的GC(Garbage Collection)。有了垃圾回收机制后，程序员只需要关心内存的申请即可，内存的释放由系统自动识别完成。在进行垃圾回收时，不同的对象引用类型，GC会采用不同的回收时机
面试官：强引用、软引用、弱引用、虚引用的区别？
候选人:
嗯嗯~强引用最为普通的引用方式，表示一个对象处于有用且必须的状态，如果一个对象具有强引用，则GC并不会回收它。即便堆中内存不足了，宁可出现OOM，也不会对其进行回收软引用表示一个对象处于有用且非必须状态，如果一个对象处于软引用，在内存空间足够的情况下，GC机制并不会回收它，而在内存空间不足时，则会在OOM异常出现之间对其进行回收。但值得注意的是，因为GC线程优先级较低，软引用并不会立即被回收。弱引用表示一个对象处于可能有用且非必须的状态。在GC线程扫描内存区域时，一旦发现弱引用，就会回收到弱引用相关联的对象。对于弱引用的回收，无关内存区域是否足够，一旦发现则会被回收。同样的，因为GC线程优先级较低，所以弱引用也并不是会被立刻回收。虚引用表示一个对象处于无用的状态。在任何时候都有可能被垃圾回收。虚引用的使用必须和引用队列Reference Queue联合使用
面试官：对象什么时候可以被垃圾器回收
候选人:
思考一会~如果一个或多个对象没有任何的引用指向它了，那么这个对象现在就是垃圾，如果定位了垃圾，则有可能会被垃圾回收器回收。如果要定位什么是垃圾，有两种方式来确定，第一个是引用计数法，第二个是可达性分析算法
通常都使用可达性分析算法来确定是不是垃圾
面试官： JVM 垃圾回收算法有哪些？
候选人:
我记得一共有四种，分别是标记清除算法、复制算法、标记整理算法、分代回收
面试官： 你能详细聊一下分代回收吗？
候选人:
关于分代回收是这样的
在java8时，堆被分为了两份：新生代和老年代，它们默认空间占用比例是1:2.对于新生代，内部又被分为了三个区域。Eden区，S0区，S1区默认空间占用比例是8:1:1
具体的工作机制是有些情况：
1）当创建一个对象的时候，那么这个对象会被分配在新生代的Eden区。当Eden区要满了时候，触发YoungGC。
2）当进行YoungGC后，此时在Eden区存活的对象被移动到S0区，并且当前对象的年龄会加1，清空Eden区。
3）当再一次触发YoungGC的时候，会把Eden区中存活下来的对象和S0中的对象，移动到S1区中，这些对象的年龄会加1，清空Eden区和S0区。
4）当再一次触发YoungGC的时候，会把Eden区中存活下来的对象和S1中的对象，移动到S0区中，这些对象的年龄会加1，清空Eden区和S1区。
5）对象的年龄达到了某一个限定的值（默认15岁 ），那么这个对象就会进入到老年代中。
当然也有特殊情况，如果进入Eden区的是一个大对象，在触发YoungGC的时候，会直接存放到老年代.当老年代满了之后，触发FullGC。FullGC同时回收新生代和老年代，当前只会存在一个FullGC的线程进行执行，其他的线程全部会被挂起。 我们在程序中要尽量避免FullGC的出现。
面试官：讲一下新生代、老年代、永久代的区别？
候选人:
嗯！是这样的，简单说就是新生代主要用来存放新生的对象。老年代主要存放应用中生命周期长的内存对象。永久代指的是永久保存区域。主要存放Class和Meta（元数据）的信息。在Java8中，永久代已经被移除，取而代之的是一个称之为“元数据区”（元空间）的区域。元空间和永久代类似，不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存的限制。
面试官：说一下 JVM 有哪些垃圾回收器？
候选人:
在jvm中，实现了多种垃圾收集器，包括：串行垃圾收集器、并行垃圾收集器（JDK8默认）、CMS（并发）垃圾收集器、G1垃圾收集器（JDK9默认）
面试官：Minor GC、Major GC、Full GC是什么
候选人:
嗯，其实它们指的是不同代之间的垃圾回收。
Minor GC 发生在新生代的垃圾回收，暂停时间短
Major GC 老年代区域的垃圾回收，老年代空间不足时，会先尝试触发Minor
GC。Minor GC之后空间还不足，则会触发Major GC，Major GC速度比较慢，暂停时间长
Full GC 新生代 + 老年代完整垃圾回收，暂停时间长，应尽力避免
面试官：JVM 调优的参数可以在哪里设置参数值？
候选人:
我们当时的项目是springboot项目，可以在项目启动的时候，java -jar中加入
参数就行了
面试官：用的 JVM 调优的参数都有哪些？
候选人:
嗯，这些参数是比较多的。我记得当时我们设置过堆的大小，像-Xms和-Xmx。还有就是可以设置年轻代中Eden区和两个Survivor区的大小比例。还有就是可以设置使用哪种垃圾回收器等等。具体的指令还真记不太清楚。
面试官：嗯，好的，你们平时调试 JVM都用了哪些工具呢？
候选人:
嗯，我们一般都是使用jdk自带的一些工具，比如
jps 输出JVM中运行的进程状态信息
jstack查看java进程内线程的堆栈信息。
jmap 用于生成堆转存快照
jstat用于JVM统计监测工具
还有一些可视化工具，像jconsole和VisualVM等
面试官：假如项目中产生了java内存泄露，你说一下你的排查思路？
候选人:
嗯，这个我在之前项目排查过。第一呢可以通过jmap指定打印他的内存快照 dump文件，不过有的情况打印不了，我们会设置vm参数让程序自动生成dump文件
第二，可以通过工具去分析 dump文件，jdk自带的VisualVM就可以分析
第三，通过查看堆信息的情况，可以大概定位内存溢出是哪行代码出了问题
第四，找到对应的代码，通过阅读上下文的情况，进行修复即可
面试官：好的，那现在再来说一种情况，就是说服务器CPU持续飙高，你的
排查方案与思路？
候选人:
嗯，我思考一下~~，可以这么做
第一可以使用使用top命令查看占用cpu的情况
第二通过top命令查看后，可以查看是哪一个进程占用cpu较高，记录这个进程id
第三可以通过ps 查看当前进程中的线程信息，看看哪个线程的cpu占用较高
第四可以jstack命令打印进行的id，找到这个线程，就可以进一步定位问题代码的行号

多线程相关面试题

面试官：聊一下并行和并发有什么区别？
候选人：
是这样的。现在都是多核CPU，在多核CPU下
并发是同一时间应对多件事情的能力，多个线程轮流使用一个或多个CPU
并行是同一时间动手做多件事情的能力，4核CPU同时执行4个线程
面试官：说一下线程和进程的区别？
候选人：
嗯，好~进程是正在运行程序的实例，进程中包含了线程，每个线程执行不同的任务不同的进程使用不同的内存空间，在当前进程下的所有线程可以共享内存空间线程更轻量，线程上下文切换成本一般上要比进程上下文切换低(上下文切换指的是从一个线程切换到另一个线程)
面试官：如果在java中创建线程有哪些方式？
候选人：
在java中一共有四种常见的创建方式，分别是：继承Thread类、实现runnable接口、实现Callable接口、线程池创建线程。通常情况下，我们项目中都会采用线程池的方式创建线程。
面试官：好的，刚才你说的runnable 和 callable 两个接口创建线程有什么不同呢？
候选人：
是这样的~最主要的两个线程一个是有返回值，一个是没有返回值的。Runnable 接口run方法无返回值；Callable接口call方法有返回值，是个泛型，和Future、FutureTask配合可以用来获取异步执行的结果还有一个就是，他们异常处理也不一样。Runnable接口run方法只能抛出运行时异常，也无法捕获处理；Callable接口call方法允许抛出异常，可以获取异常信息。在实际开发中，如果需要拿到执行的结果，需要使用Callalbe接口创建线程，调用FutureTask.get()得到可以得到返回值，此方法会阻塞主进程的继续往下执行，如果不调用不会阻塞。
面试官：线程包括哪些状态，状态之间是如何变化的？
候选人：
在JDK中的Thread类中的枚举State里面定义了6中线程的状态分别是：新建、可运行、终结、阻塞、等待和有时限等待六种。关于线程的状态切换情况比较多。我分别介绍一下当一个线程对象被创建，但还未调用 start 方法时处于新建状态，调用了start 方法，就会由新建进入可运行状态。如果线程内代码已经执行完毕，由可运行进入终结状态。当然这些是一个线程正常执行情况。如果线程获取锁失败后，由可运行进入 Monitor 的阻塞队列阻塞，只有当持锁线程释放锁时，会按照一定规则唤醒阻塞队列中的阻塞线程，唤醒后的线程进入可运行状态。如果线程获取锁成功后，但由于条件不满足，调用了 wait() 方法，此时从可运行状态释放锁等待状态，当其它持锁线程调用 notify() 或 notifyAll() 方
法，会恢复为可运行状态。还有一种情况是调用 sleep(long) 方法也会从可运行状态进入有时限等待状态，不需要主动唤醒，超时时间到自然恢复为可运行状态
面试官：嗯，好的，刚才你说的线程中的 wait 和 sleep方法有什么不同呢？
候选人：
它们两个的相同点是都可以让当前线程暂时放弃 CPU 的使用权，进入阻塞状态。
不同点主要有三个方面：
第一：方法归属不同
sleep(long) 是 Thread 的静态方法。而 wait()，是 Object 的成员方法，每个对象都有
第二：线程醒来时机不同
线程执行 sleep(long) 会在等待相应毫秒后醒来，而 wait() 需要被 notify 唤醒，wait() 如果不唤醒就一直等下去
第三：锁特性不同
wait 方法的调用必须先获取 wait 对象的锁，而 sleep 则无此限制
wait 方法执行后会释放对象锁，允许其它线程获得该对象锁（相当于我放弃cpu，但你们还可以用）
而 sleep 如果在 synchronized 代码块中执行，并不会释放对象锁（相当于我放弃 cpu，你们也用不了）
面试官：好的，我现在举一个场景，你来分析一下怎么做，新建 T1、T2、T3 三个线程，如何保证它们按顺序执行？
候选人：
嗯~，我思考一下 （适当的思考或想一下属于正常情况，脱口而出反而太假[背诵痕迹]）
可以这么做，在多线程中有多种方法让线程按特定顺序执行，可以用线程类的join()方法在一个线程中启动另一个线程，另外一个线程完成该线程继续执行。
比如说：
使用join方法，T3调用T2，T2调用T1，这样就能确保T1就会先完成而T3最后完成
面试官：在我们使用线程的过程中，有两个方法。线程的 run()和 start()有什么区别？
候选人：
start方法用来启动线程，通过该线程调用run方法执行run方法中所定义的逻辑代码。start方法只能被调用一次。run方法封装了要被线程执行的代码，可以被调用多次。
面试官：那如何停止一个正在运行的线程呢？
候选人：
有三种方式可以停止线程
第一：可以使用退出标志，使线程正常退出，也就是当run方法完成后线程终止，一般我们加一个标记
第二：可以使用线程的stop方法强行终止，不过一般不推荐，这个方法已作废
第三：可以使用线程的interrupt方法中断线程，内部其实也是使用中断标志来中断线程
我们项目中使用的话，建议使用第一种或第三种方式中断线程
面试官：讲一下synchronized关键字的底层原理？
候选人：
嗯~好的，synchronized 底层使用的JVM级别中的Monitor 来决定当前线程是否获得了锁，如果某一个线程获得了锁，在没有释放锁之前，其他线程是不能或得到锁的。synchronized 属于悲观锁。
synchronized 因为需要依赖于JVM级别的Monitor ，相对性能也比较低。
面试官：好的，你能具体说下Monitor 吗？
候选人：
monitor对象存在于每个Java对象的对象头中，synchronized 锁便是通过这种方式获取锁的，也是为什么Java中任意对象可以作为锁的原因monitor内部维护了三个变量
WaitSet：保存处于Waiting状态的线程
EntryList：保存处于Blocked状态的线程
Owner：持有锁的线程
只有一个线程获取到的标志就是在monitor中设置成功了Owner，一个monitor中只能有一个Owner
在上锁的过程中，如果有其他线程也来抢锁，则进入EntryList 进行阻塞，当获得锁的线程执行完了，释放了锁，就会唤醒EntryList 中等待的线程竞争锁，竞争的时候是非公平的。
面试官：好的，那关于synchronized 的锁升级的情况了解吗？
候选人：
嗯，知道一些（要谦虚）
Java中的synchronized有偏向锁、轻量级锁、重量级锁三种形式，分别对应了锁只被一个线程持有、不同线程交替持有锁、多线程竞争锁三种情况。重量级锁：底层使用的Monitor实现，里面涉及到了用户态和内核态的切换、进程的上下文切换，成本较高，性能比较低。
轻量级锁：线程加锁的时间是错开的（也就是没有竞争），可以使用轻量级锁来优化。轻量级修改了对象头的锁标志，相对重量级锁性能提升很多。每次修改都是CAS操作，保证原子性
偏向锁：一段很长的时间内都只被一个线程使用锁，可以使用了偏向锁，在第一次获得锁时，会有一个CAS操作，之后该线程再获取锁，只需要判断mark word中是否是自己的线程id即可，而不是开销相对较大的CAS命令。一旦锁发生了竞争，都会升级为重量级锁
面试官：好的，刚才你说了synchronized它在高并发量的情况下，性能不高，在项目该如何控制使用锁呢？
候选人：
嗯，其实，在高并发下，我们可以采用ReentrantLock来加锁。
面试官：嗯，那你说下ReentrantLock的使用方式和底层原理？
候选人：
好的，ReentrantLock是一个可重入锁:，调用 lock 方 法获取了锁之后，再次调用lock，是不会再阻塞，内部直接增加重入次数 就行了，标识这个线程已经重复获取一把锁而不需要等待锁的释放。
ReentrantLock是属于juc报下的类，属于api层面的锁，跟synchronized一样，都是悲观锁。通过lock()用来获取锁，unlock()释放锁。它的底层实现原理主要利用CAS+AQS队列来实现。它支持公平锁和非公平锁，两者的实现类似。构造方法接受一个可选的公平参数（默认非公平锁），当设置为true时，表示公平锁，否则为非公平锁。公平锁的效率往往没有非公平锁的效率高。
面试官：好的，刚才你说了CAS和AQS，你能介绍一下吗？
候选人：
好的。CAS的全称是： Compare And Swap(比较再交换);它体现的一种乐观锁的思想，在无锁状态下保证线程操作数据的原子性。CAS使用到的地方很多：AQS框架、AtomicXXX类在操作共享变量的时候使用的自旋锁，效率上更高一些CAS的底层是调用的Unsafe类中的方法，都是操作系统提供的，其他语言实现AQS的话，其实就一个jdk提供的类AbstractQueuedSynchronizer，是阻塞式锁和相关的同步器工具的框架。内部有一个属性 state 属性来表示资源的状态，默认state等于0，表示没有获取锁，state等于1的时候才标明获取到了锁。通过cas 机制设置 state 状态。在它的内部还提供了基于 FIFO 的等待队列，是一个双向列表，其中
tail 指向队列最后一个元素
head 指向队列中最久的一个元素
其中我们刚刚聊的ReentrantLock底层的实现就是一个AQS。
面试官：synchronized和Lock有什么区别 ?
候选人：
嗯~，好的，主要有三个方面不太一样
第一，语法层面
synchronized 是关键字，源码在 jvm 中，用 c++ 语言实现，退出同步代码块锁会自动释放
Lock 是接口，源码由 jdk 提供，用 java 语言实现，需要手动调用 unlock 方法释放锁
第二，功能层面
二者均属于悲观锁、都具备基本的互斥、同步、锁重入功能
Lock 提供了许多 synchronized 不具备的功能，例如获取等待状态、公平锁、可打断、可超时、多条件变量，同时Lock 可以实现不同的场景，如 ReentrantLock，
ReentrantReadWriteLock
第三，性能层面
在没有竞争时，synchronized 做了很多优化，如偏向锁、轻量级锁，性能不赖在竞争激烈时，Lock 的实现通常会提供更好的性能统合来看，需要根据不同的场景来选择不同的锁的使用。
面试官：死锁产生的条件是什么？
候选人：
嗯，是这样的，一个线程需要同时获取多把锁，这时就容易发生死锁，举个例子来说：
t1 线程获得A对象锁，接下来想获取B对象的锁
t2 线程获得B对象锁，接下来想获取A对象的锁
这个时候t1线程和t2线程都在互相等待对方的锁，就产生了死锁
面试官：那如果产出了这样的，如何进行死锁诊断？
候选人：
这个也很容易，我们只需要通过jdk自动的工具就能搞定。我们可以先通过jps来查看当前java程序运行的进程id。然后通过jstack来查看这个进程id，就能展示出来死锁的问题，并且，可以定位代码的具体行号范围，我们再去找到对应的代码进行排查就行了。
面试官：请谈谈你对 volatile 的理解
候选人：
嗯~
volatile 是一个关键字，可以修饰类的成员变量、类的静态成员变量，主要有两个功能
第一：保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的,volatile关键字会强制。将修改的值立即写入主存。
第二： 禁止进行指令重排序，可以保证代码执行有序性。底层实现原理是，添加了一个内存屏障，通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化
面试官：那你能聊一下ConcurrentHashMap的原理吗？
候选人：
嗯好的，
ConcurrentHashMap 是一种线程安全的高效Map集合，jdk1.7和1.8也做了很多调整。
JDK1.7的底层采用是分段的数组+链表 实现JDK1.8 采用的数据结构跟HashMap1.8的结构一样，数组+链表/红黑二叉树。在jdk1.7中 ConcurrentHashMap 里包含一个 Segment 数组。Segment 的结构
和HashMap类似，是一 种数组和链表结构，一个 Segment 包含一个HashEntry 数组，每个 HashEntry 是一个链表结构 的元素，每个 Segment 守护着一个HashEntry数组里的元素，当对 HashEntry 数组的数据进行修 改时，必须首先获得对应的 Segment的锁。Segment 是一种可重入的锁 ReentrantLock，每个 Segment 守护一个HashEntry 数组里得元 素，当对 HashEntry 数组的数据进行修改时，必须首先获得对应的 Segment 锁。在jdk1.8中的ConcurrentHashMap 做了较大的优化，性能提升了不少。首先是它的数据结构与jdk1.8的hashMap数据结构完全一致。其次是放弃了
Segment臃肿的设计，取而代之的是采用Node + CAS + Synchronized来保 证并发安全进行实现，synchronized只锁定当前链表或红黑二叉树的首节点，这样只要hash不冲 突，就不会产生并发 , 效率得到提升。
面试官：线程池的种类有哪些？
候选人：
嗯！是这样
在jdk中默认提供了4中方式创建线程池
第一个是：newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回 收空闲线程，若无可回收，则新建线程。
第二个是：newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列 中等待。
第三个是：newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。
第四个是：newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任 务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。
面试官：线程池的核心参数有哪些？
候选人：
在线程池中一共有7个核心参数：1. corePoolSize 核心线程数目 - 池中会保留的最多线程数。2. maximumPoolSize 最大线程数目 - 核心线程+救急线程的最大数目。3. keepAliveTime 生存时间 - 救急线程的生存时间，生存时间内没有新任务，此线程资源会释放4. unit 时间单位 - 救急线程的生存时间单位，如秒、毫秒等5. workQueue - 当没有空闲核心线程时，新来任务会加入到此队列排队，队列满会创建救急线程执行任务6. threadFactory 线程工厂 - 可以定制线程对象的创建，例如设置线程名字、是否是守护线程等7. handler 拒绝策略 - 当所有线程都在繁忙，workQueue 也放满时，会触发拒绝策略 在拒绝策略中又有4种拒绝策略。 当线程数过多以后，第一种是抛异常、第二种是由调用者执行任务、第三是丢弃当前的任务，第四是丢弃最早排队任务。默认是直接抛异常。
面试官：如何确定核心线程池呢？
候选人：
是这样的，我们公司当时有一些规范，为了减少线程上下文的切换，要根据当时部署的服务器的CPU核数来决定，我们规则是：CPU核数+1就是最终的核心线程数。
面试官：线程池的执行原理知道吗？
候选人：
嗯~，它是这样的。首先判断线程池里的核心线程是否都在执行任务，如果不是则创建一个新的
工作线程来执行任务。如果核心线程都在执行任务，则线程池判断工作队列是否已满，如果工作队列没有满，则将新提交的任务存储在这个工作队 列里。如果工作队列满了，则判断线程池里的线程是否都处于工作状态，如果没有，则创建一个新的工作线程来执行任 务。如果已经满了，则交给拒绝策
略来处理这个任务。
面试官：为什么不建议使用Executors创建线程池呢？
候选人：
好的，其实这个事情在阿里提供的最新开发手册《Java开发手册-嵩山版》中也提到了。主要原因是如果使用Executors创建线程池的话，它允许的请求队列默认长度是Integer.MAX_VALUE，这样的话，有可能导致堆积大量的请求，从而导致OOM（内存溢出）。所以，我们一般推荐使用ThreadPoolExecutor来创建线程池，这样可以明确规定线程池的参数，避免资源的耗尽。
面试官：如果控制某一个方法允许并发访问线程的数量？
候选人：
嗯~，我想一下，在jdk中提供了一个Semaphore[seməfɔːr]类（信号量）。它提供了两个方法，semaphore.acquire() 请求信号量，可以限制线程的个数，是一个正数，如果信号量是-1,就代表已经用完了信号量，其他线程需要阻塞了
第二个方法是semaphore.release()，代表是释放一个信号量，此时信号量的个数+1
面试官：好的，那该如何保证Java程序在多线程的情况下执行安全呢？
候选人：
嗯，刚才讲过了导致线程安全的原因，如果解决的话，jdk中也提供了很多的类帮助我们解决多线程安全的问题，比如：
JDK Atomic开头的原子类、synchronized、LOCK，可以解决原子性问题。synchronized、volatile、LOCK，可以解决可见性问题。Happens-Before 规则可以解决有序性问题
面试官：你在项目中哪里用了多线程？
候选人：
嗯~，我想一下当时的场景[根据自己简历上的模块设计多线程场景]
参考场景一：
es数据批量导入。在我们项目上线之前，我们需要把数据量的数据一次性的同步到es索引库
中，但是当时的数据好像是1000万左右，一次性读取数据肯定不行（oom异常），如果分批执行的话，耗时也太久了。所以，当时我就想到可以使用线程池的方式导入，利用CountDownLatch+Future来控制，就能大大提升导入的时间。
参考场景二：
在我做那个xx电商网站的时候，里面有一个数据汇总的功能，在用户下单之后需要查询订单信息，也需要获得订单中的商品详细信息（可能是多个），还需要查看物流发货信息。因为它们三个对应的分别三个微服务，如果一个一个的操作的话，互相等待的时间比较长。所以，我当时就想到可以使用线
程池，让多个线程同时处理，最终再汇总结果就可以了，当然里面需要用到Future来获取每个线程执行之后的结果才行
参考场景三：
我当时做了一个文章搜索的功能，用户输入关键字要搜索文章，同时需要保存用户的搜索记录（搜索历史），这块我设计的时候，为了不影响用户的正常搜索，我们采用的异步的方式进行保存的，为了提升性能，我们加入了线程池，也就说在调用异步方法的时候，直接从线程池中获取线程使用
面试官：谈谈你对ThreadLocal的理解
候选人：
嗯，是这样的~，ThreadLocal 主要功能有两个，第一个是可以实现资源对象的线程隔离，让每个线程各用各的资源对象，避免争用引发的线程安全问题，第二个是实现了线程内的资源共享
面试官：好的，那你知道ThreadLocal的底层原理实现吗？
候选人：
嗯，知道一些~在ThreadLocal内部维护了一个一个 ThreadLocalMap 类型的成员变量，用来存储资源对象当我们调用 set 方法，就是以 ThreadLocal 自己作为 key，资源对象作为value，放入当前线程的 ThreadLocalMap 集合中当调用 get 方法，就是以 ThreadLocal 自己作为 key，到当前线程中查找关联的资源值。当调用 remove 方法，就是以 ThreadLocal 自己作为 key，移除当前线程关联的资源值
面试官：好的，那关于ThreadLocal会导致内存溢出这个事情，了解吗？
候选人：
嗯，我之前看过源码，我想一下~是应为ThreadLocalMap 中的 key 被设计为弱引用，它是被动的被GC调用释放key，不过关键的是只有key可以得到内存释放，而value不会，因为value是一个强引用。
在使用ThreadLocal 时都把它作为静态变量（即强引用），因此无法被动依靠 GC 回收，建议主动的remove 释放 key，这样就能避免内存溢出。

常见技术场景

1.单点登录这块怎么实现的

单点登录的英文名叫做：Single Sign On（简称SSO）,只需要登录一次，就可以访问所有信任的应用系统
在以前的时候，一般我们就单系统，所有的功能都在同一个系统上。
单体系统的session共享
登录：将用户信息保存在Session对象中
如果在Session对象中能查到，说明已经登录
如果在Session对象中查不到，说明没登录（或者已经退出了登录）
注销（退出登录）：从Session中删除用户的信息
后来，我们为了合理利用资源和降低耦合性，于是把单系统拆分成多个子系统。
多系统即可能有多个Tomcat，而Session是依赖当前系统的Tomcat，所以系统A的Session和系统B的Session是不共享的。解决系统之间Session不共享问题有一下几种方案：
Tomcat集群Session全局复制（最多支持5台tomcat，不推荐使用）
JWT(常见)
Oauth2
CAS
自己实现（redis+token）
1.2 JWT解决单点登录
现在有一个微服务的简单架构，如图：

使用jwt解决单点登录的流程如下：

1.3 回答要点
1，先解释什么是单点登录
单点登录的英文名叫做：Single Sign On（简称SSO）
2，介绍自己项目中涉及到的单点登录（即使没涉及过，也可以说实现的思路）
3，介绍单点登录的解决方案，以JWT为例
I. 用户访问其他系统，会在网关判断token是否有效
II. 如果token无效则会返回401（认证失败）前端跳转到登录页面
III. 用户发送登录请求，返回浏览器一个token，浏览器把token保存到cookie
IV. 再去访问其他服务的时候，都需要携带token，由网关统一验证后路由到目标服务

2.权限认证是如何实现的

2.1 概述
后台的管理系统，更注重权限控制，最常见的就是RBAC模型来指导实现权限
RBAC(Role-Based Access Control)基于角色的访问控制
3个基础部分组成：用户、角色、权限
具体实现
5张表（用户表、角色表、权限表、用户角色中间表、角色权限中间表）
7张表（用户表、角色表、权限表、菜单表、用户角色中间表、角色权限中间表、权限菜单中间表）
2.2 RBAC权限模型
最常见的5张表的关系

数据流转
张三具有什么权限呢？
流程：张三登录系统—> 查询张三拥有的角色列表—>再根据角色查询拥有的权限

在实际的开发中，也会使用权限框架完成权限功能的实现，并且设置多种粒度，
常见的框架有：
Apache shiro
Spring security（推荐）
2.3 回答要点
后台管理系统的开发经验
介绍RBAC权限模型5张表的关系（用户、角色、权限）
权限框架：Spring security

3.上传数据的安全性你们怎么控制？

3.1 概述

这里的安全性，主要说的是，浏览器访问后台，需要经过网络传输，有可能会出现安全的问题。
解决方案：使用非对称加密（或对称加密），给前端一个公钥让他把数据加密后传到后台，后台负责解密后处理数据
3.2 对称加密
文件加密和解密使用相同的密钥，即加密密钥也可以用作解密密钥

数据发信方将明文和加密密钥一起经过特殊的加密算法处理后，使其变成复杂的加密密文发送出去，
收信方收到密文后，若想解读出原文，则需要使用加密时用的密钥以及相同
加密算法的逆算法对密文进行解密，才能使其回复成可读明文。
在对称加密算法中，使用的密钥只有一个，收发双方都使用这个密钥，这就需要解密方事先知道加密密钥。
优点: 对称加密算法的优点是算法公开、计算量小、加密速度快、加密效率高。
缺点: 没有非对称加密安全.
用途： 一般用于保存用户手机号、身份证等敏感但能解密的信息。
常见的对称加密算法有: AES、DES、3DES、Blowfish、IDEA、RC4、RC5、RC6、HS2
56
3.3 非对称加密
两个密钥：公开密钥（publickey）和私有密钥，公有密钥加密，私有密钥解密

解释: 同时生成两把密钥：私钥和公钥，私钥隐秘保存，公钥可以下发给信任客户端.
加密与解密:
私钥加密，持有公钥才可以解密
公钥加密，持有私钥才可解密
签名:
私钥签名, 持有公钥进行验证是否被篡改过.
优点: 非对称加密与对称加密相比，其安全性更好；
缺点: 非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。
用途： 一般用于签名和认证。私钥服务器保存, 用来加密, 公钥客户拿着用于对于令牌或者签名的解密或者校验使用.
常见的非对称加密算法有： RSA、DSA（数字签名用）、ECC（移动设备用）、
RS256 (采用SHA-256 的 RSA 签名)
3.4 回答要点
使用非对称加密（或对称加密），给前端一个公钥让他把数据加密后传到后台，后台解密后处理数据
传输的数据很大建议使用对称加密，不过不能保存敏感信息
传输的数据较小，要求安全性高，建议采用非对称加密

4.你们项目中日志怎么采集的

1，为什么要采集日志？
日志是定位系统问题的重要手段，可以根据日志信息快速定位系统中的问题
2，采集日志的方式有哪些?
ELK：即Elasticsearch、Logstash和Kibana三个软件的首字母
常规采集：按天保存到一个日志文件
ELK基本架构
ELK即Elasticsearch、Logstash和Kibana三个开源软件的缩写

Elasticsearch
Elasticsearch 全文搜索和分析引擎，对大容量的数据进行接近实时的存储、搜索和分析操作。
Logstash
Logstash是一个数据收集引擎，它可以动态的从各种数据源搜集数据，并对数据进行过滤、分析和统一格式等操作，并将输出结果存储到指定位置上
Kibana
Kibana是一个数据分析和可视化平台，通常与Elasticsearch配合使用，用于对其中的数据进行搜索、分析，并且以统计图标的形式展示。
参考回答
我们搭建了ELK日志采集系统
介绍ELK的三个组件：
Elasticsearch是全文搜索分析引擎，可以对数据存储、搜索、分析
Logstash是一个数据收集引擎，可以动态收集数据，可以对数据进行过滤、分析，将数据存储到指定的位置
Kibana是一个数据分析和可视化平台，配合Elasticsearch对数据进行搜索，分析，图表化展示

5.查看日志的命令

目前采集日志的方式：按天保存到一个日志文件

也可以在logback配置文件中设置日志的目录和名字

需要掌握的Linux中的日志：
实时监控日志的变化：
实时监控某一个日志文件的变化：tail -f xx.log；实时监控日志最后100行日志： tail –n 100 -f xx.log
按照行号查询：
查询日志尾部最后100行日志：tail – n 100 xx.log
查询日志头部开始100行日志：head –n 100 xx.log
查询某一个日志行号区间：cat -n xx.log | tail -n +100 | head -n 100 (查询
100行至200行的日志)
按照关键字找日志的信息
查询日志文件中包含debug的日志行号：cat -n xx.log | grep “debug”
按照日期查询
sed -n '/2023-05-18 14:22:31.070/,/ 2023-05-18 14:27:14.158/p’xx.log
日志太多，处理方式
分页查询日志信息：cat -n xx.log |grep “debug” | more
筛选过滤以后，输出到一个文件：cat -n xx.log | grep “debug” >debug.txt

6.生产问题怎么排查

已经上线的bug排查的思路：
1，先分析日志，通常在业务中都会有日志的记录，或者查看系统日志，或者查看日志文件，然后定位问题
2，远程debug(通常公司的正式环境（生产环境）是不允许远程debug的。一般远程debug都是公司的测试环境，方便调试代码)
远程debug配置
前提条件：远程的代码和本地的代码要保持一致
1.远程代码需要配置启动参数，把项目打包放到服务器后启动项目的参数：

-agentlib:jdwp 是通知JVM使用(java debug wire protocol)来运行调试环境
transport=dt_socket 调试数据的传送方式
server=y 参数是指是否支持在server模式
suspend=n 是否在调试客户端建立起来后，再执行JVM。
address=5005 调试端口设置为5005，其它端口也可以

2.idea中设置远程debug，找到idea中的 Edit Configurations…

3. idea中启动远程debug
4.访问远程服务器，在本地代码中打断点即可调试远程

7.怎么快速定位系统的瓶颈

1.压测（性能测试），项目上线之前测评系统的压力
压测目的：给出系统当前的性能状况；定位系统性能瓶颈或潜在性能瓶颈
指标：响应时间、 QPS、并发数、吞吐量、 CPU利用率、内存使用率、磁盘IO、错误率
压测工具：LoadRunner、Apache Jmeter …
后端工程师：根据压测的结果进行解决或调优（接口慢、代码报错、并发
达不到要求…）
2.监控工具、链路追踪工具，项目上线之后监控
监控工具：Prometheus+Grafana
链路追踪工具：skywalking、Zipkin
3.线上诊断工具Arthas(阿尔萨斯)，项目上线之后监控、排查