JAVA基础八股文
问：java中序列化是怎么实现的呢？
1.实现Serializable接口，就会实现数据序列化的效果。
2.调用json做序列化。（就比如：Jackson，fastjson等等）
3.实现Enternalizable接口，就可以实现反序列化的效果。
问:java的流有哪些呢？
从方向方面，主要就是输入流和输出流。
从单位方面，主要就是分为字节流和字符流。字节流主要就是InputStream，OutputStream。字符流主要就是Reader，Writer。
问：抽象类和接口有什么区别呢？
从方法编写方面，抽象类中可以抽象方法和普通方法，而接口中只能编写抽象方法。
从继承和实现方面，抽象方法只能继承一个类并且可以实现多个接口，而接口可以继承多个接口。
在变量的定义方面，接口只能定义静态变量，抽象类可以定义普通变量和静态变量。
问：final关键值有了解过吗？
在修饰方法的时候，说明该方法无法被重写。
在修饰类的时候，说明该类无法被继承。
在修饰属性的时候，说明该变量从创建到销毁过程中不会改变。
在修饰形参的时候，说明该形参的引用在方法执行前后都会不发生改变。
问：异常类有哪些？
异常主要就是Exception，Error。
Exception主要就是运行时异常和检查时异常，为了保证代码恶的正常运行，我们需要主动使用try/catch进行捕获，常见的就是IoEception，SQLExceptinon。
Error主要就是就是发生在运行时的异常，就比如：oom，threadDeath。
问：Filter和Interceptor有说明区别？哪个先执行呢？
- 在作用域方面，Filter作用域每个请求，而interceptor主要就是对Controller方法的请求起作用。
- 在执行时机方面，filter会在请求加入dispatchServlet前和返回给客户端前执行，而interceptor会在执行Controller方法的时候和进行视图渲染前执行。
- Filter会像执行而interceptor随后执行。
问：java中共享变量有哪些？
1.静态变量。
2.使用Voliate修饰java中得变量就会变成共享变量。
问：编写sigleton函数?（单例模式）
饿汉式：
public class sigleton {
//饿汉式,每次都会创建好,即使没有调用
private final static Test test = new Test();
public Test getInstance() {
return test;
}
}懒汉式：
public class sigleton {
//懒汉式，只有在被第一次调用时才会被创建
private static Test test;
public Test getInstance() {
return test == null ? new Test() : test;
}
}
Redis八股文
问：Redis数据结构的底层实现由了解过吗？
String类型的底层使用动态字符串实现的。
List类型的底层使用双向链表+压缩数组实现的。
set类型的底层使用哈希表+数组整数数组实现的。
hash类型的底层使用压缩数组+哈希表实现的。
zset类型的底层使用压缩数组+跳表实现的。
问：zset的底层结构有了解过吗？
zset的底层结构主要就是跳表+压缩列表。
压缩列表：本质就是一个数组，在其中记录 列表的长度，尾部得偏移量，列表的个数。
跳表：就是基于二分查找的思想，对链表创建多级索引，就是基于每隔一个节点做索引，以此类推，创建索引的层数就是 logn + 1。整个查找过程就是在多级索引间跳来跳去。
问：我看你在做项目的时候都使用到redis，你在最近的项目中哪些场景下使用redis呢?
缓存和分布式锁都有使用到。
问：说说在缓存方面使用
1.在我最写的物流项目中就使用redis作为缓存，当然在业务中还是比较复杂的。
2.在物流信息查询模块使用中使用二级缓存，一级缓存使用的是Caffeine，二级缓存就是使用redis。
问：对缓存击穿，缓存雪崩，缓存穿透有了解过吗？说说者三个缓存问题的解决方案吧。
1.缓存击穿：某个热点key设置了过期时间，在高并发查询的情况下，该热点key过期了，导致大量的请求去访问数据库，最终压垮数据库。
解决方案：
（1）不给热点key设置过期时间（在redis中设置的过期时间都是逻辑过期时间，通过逻辑字段来判断key是否过期）。
（2）使用分布式锁，保证每次只有一个请求去访问数据库，在每次访问数据库前再做一次查询缓存的操作，然后获取锁并去数据库查询，将查到的数据重新缓存起来，下一次请求就会在缓存中查询到数据，就不会查询数据库，防止压垮数据库。
2.缓存雪崩：第一种情况:大量的key设置了相同的过期时间，在同一大量的key失效，导致大量的请求去访问数据库，导致压垮数据库。第二种情况:redis宕机。
解决方案:
(1) 错开key的过期时间（TTL）：在每个key的统一过期时间上在随机加上1~5分钟的过期时间。
(2)设置服务降级，服务熔断，服务限流，到达阈值的时候直接返回自定义的错误信息。（作为系统的兜底策略）
(3)为redis搭建集群,就包括哨兵模式，集群模式。
(4)做二级缓存。（可以重点介绍，就引导面试官到运单信息查询模块，给他介绍二级缓存的实现还有缓存同步的问题，主要讲caffeine缓存同步的问题）
3.缓存穿透:查询的key在缓存和数据库中都不存在，每次都会进入数据库查询，当大量的这种key访问数据库，就会导致缓存穿透。（这种情况多半上是恶意攻击）
解决方案:
(1)在缓存中储存空值：当在数据库中没有查到数据时，将key关联null的键值对存储到缓存中，后续就会走缓存，这种解决方案缺点很明显，就是存储大量无用的存储，浪费空间。
(2)使用布隆过滤器：在查询缓存的时候先去布隆过滤器中查询是否存在缓存，再去查询缓存。
问：具体讲讲你对这个布隆过滤器理解？
布隆过滤器类似hash表叫做bitmap(位图)，在没有位置存放的是二进制的数据，1表示存在，0表示不存在。通过哈希函数计算储存位置。在后续查询缓存前先去布隆过滤器中查询数据是否存在，如果存在才去查缓存，如果不存在就直接返回空。
布隆过滤器的优点就是：储存二进制的数据，而非真实的数据，查询速度快。缺点：判断数据是否存在有误判率，不能做删除操作。
为了降低布隆过滤器的误判率，因为两个数据的hashCode可能相同，所以我们可以设置多哈希函数操作，较低过滤器的误判率。
我们主要是根据redisson设置布隆过滤器，可以设置其误判率。在高并发的场景下，一般误判率控制在5%之内就可以了。
问：说说分布式锁方面的使用
在项目的支付模块中的扫码支付为了保证交易单的状态不会被除当前业务的其他业务修改，计算运力，我们都会使用分布式锁。
问：你能简单的讲述一下分布式锁的实现吗？（引导面试官到你的项目中，去解释）
分布式锁
可以跟面试官说说优惠劵超卖的问题。
在redisson中的获取锁方法底层主要是通过Lua（能够调用redis命令，保证命令执行的原子性）实现的，如果获取锁方法没有设置过期时间，则分布式锁会有watch dog来保证延长锁的有效时间。
还可以通过setnx来实现分布式锁(因为redis是单线程的)。 通过 set If not exists并设置过期时间实现分布式锁，但是存在的问题就是无法确定要给锁设置多长的有效时间，所以在项目中比较少使用。
公平锁 (我们项目中使用的分布式锁，保证可重入性)
公平锁主要还是基于redisson实现的。锁的结构采用的是hash结构，以大小key的形式，在我业务中，使用订单id和交易单id进行拼接作为大key，使用当前的线程id作为小key,vlaue存放的就是上锁的次数。在业务修改交易单状态是需要先判断当前交易单是否被上锁（通过订单id，交易单id，进程id来获取对应的锁），如果被上锁，则当前线程的其他业务不能进行操作。保证订单状态的准确性。(判断幂等性) 保证可重入性，根据当前线程id来获取分布式锁，解决死锁的情况（分布式锁的底层实现）。
问：分布式锁可以实现重入吗？
重入的意思就是：在同一个线程中获取锁后继续获取锁。因为我们分布式锁中小key使用的是线程id，value就是上锁的次数，我们每次进行重入时就是value值+1，在释放锁的时候，就将对应的value-1，在value为0的时候就删除对应的信息。其他微服务就可以获取此分布式锁了。通过线程id的不同来保证分布式锁的互斥。（蓝字选答）
问：redisson实现的分布式锁，可以解决主从一致性的问题吗？
不能解决主从一致的问题，单master节点获取锁后就没释放锁就宕机了，此时slave节点变成了master节点，因为新的master没有上锁，所以新的master会进行上锁，破坏了锁的互斥性。为了解决这个问题我们可以使用红锁，也就是给一般以上的节点添加分布式锁，但是这样效率就变的很低，为了提高效率，建议采用zookeeper实现分布式锁。（听说过zookeeper实现分布式锁）
问：在集群的项目中为什么不能用关键字synchronized呢？
在两个微服务中，如果使用synchronized是无法达到同步上锁效果，因为两个微服务是两个单独的JVM。
问：了解过双写一致性吗？
双写一致性：当数据库中的数据发生修改的时候，我们需要修改缓存中的数据，保证数据库和缓存中的信息相同。
在读操作的时候，会先到缓存中查询数据，如果没有命中的话就到数据库中查询。
在写操作的时候，会采用延迟双删。
问：在延迟双删中为什么要延迟删除缓存？
数据库采用的是主从模式，遵循读写分离，需要一些时间来将主数据库中的数据同步到从数据库，但是还是可能出现脏读的情况。
问：在延迟双删中为什么要删除两次缓存呢?
如果只有一次删除缓存操作的话就会有两种情况。
1.情况1：先删除缓存，再修改数据库。线程1删除缓存。在线程1要修改数据库前。线程2去做查询操作，发现没有缓存，就去数据库中查询数据并做缓存，之后线程1修改了数据库中的信息，最终出现缓存数据和数据库数据不相同的情况。（当前线程在删除缓存并且在写数据库前其他线程查询了就的数据）
2.情况2：先修改数据，再删除缓存。当前缓存中方没有数据，线程1做查询操作，准备将旧数据缓存前，线程2做了修改数据和删除缓存的操作(此时是没有缓存的)，最终缓存中就存储了旧的数据，出现脏读的情况。（当前线程要将旧的数据进行缓存的过程中进行了写数据库和删除缓存的操作）
为了防脏读的缓存被使用，所以在数据同步的需要两次删除缓存的操作。
问：延迟双删是没法保证强一致性的，有什么强一致性的方法吗？
方法一：使用分布式锁，每次只有一个线程进行操作，效率比较低下。
方法二：因为缓存中的数据大多是读多写少，所以我们可以使用在读取数据的时候使用共享锁， 多个线程同时可以读取缓存但是其他线程不可以写，在修改数据的时候使用排他锁，会阻塞其他线程的读写操作。
排他锁和共享锁可以使用redisson实现，通过redissonClient获取对应的读写锁。
1.读锁也就是共享锁。
2.写锁也就是排他锁。
必须保证读写锁的名字相同。
问：那有了解过最终一致性的方法吗？
在我们支付模块中，每次支付都需要获取支付模板也就是支付宝支付和微信支付模板，这些数据我们基本上不会修改，会将其缓存起来，在修改mysql中模板的数据的时候，通过rabbitmq发送消息，异步修改缓存的数据，达到最终一致的效果。
为什么mq可以实现最终一致的效果呢？
mq中的消息都是按照顺序进行消费的，消息的消费是和事务绑定的，如果事务进行了回滚操作则被消费的消息也会被重新放回队列的原先位置中，并且接收到消息的服务会异步进行处理。
当然我们不仅仅可以使用rabbitmq实现最终一致的效果，我们还可以使用canal实现最终一致的效果。canal主要是通过mysql的主从同步实现的。通过监听bin Log日志的方式来修改缓存中的信息，达到最终一致的效果。（binLog日志主要是储存DDL(数据定义语句)和DML(数据操纵语句)）
问：redis做为缓存，数据的持久化是怎么做的呢？
在持久化上用 RDB和AOF两种方式。
问:说说你对RDB和AOF的理解吧。
1.RDB：通过对数据做快照的方式做持久化，将快照存放到磁盘上，后续需要恢复数据的时间就使用该快照进行恢复。
RDB的执行原理：在主进程会有一个页表文件(用于映射数据在物理内存上的数据)，通过复制该页表到子进程中，子进程通过页表找到数据并做快照。
当是如果在修改数据的过程中做RDB就会出现脏读的情况，RDB通过设置数据为只读，在修改数据的时候复制一份相同的数据进行修改如何修改页表的映射，最终解决脏读的问题。
2.AOF：在redis做操写的指令的时候，会将这些指令都存储到对应的AOF文件中，在后续数据需要恢复的时候就执行AOF文件中的所有指令。
AOF执行的原理：就是每次去记录操作写的指令到AOF文件中。
问：RDB和AOF有什么区别吗?
1.RDB是对整个内存做快照，而AOF是记录redis每一条执行的语句。
2.RDB的在两次备份间可能会出现数据丢失的情况(redis宕机)完整性低， 而AOF的完整性比较高，其取决去刷盘的策略。
3.RDB的文件比较小，而AOF会记录每日一条指令，所以AOF的文件比较大。
4.RDB的数据恢复比较快，因为AOF文件比较大，需要一条条的执行指令，恢复速度慢。
5.RDB系统占用高，需要大量的CPU和内存的消耗，而AOF系统占用比较小，只要是文件的IO操作，但是在AOF文件重写的时候需要大量的CPU和内存的消耗。
问：RDB和AOF谁的恢复速度更快，我们在平时要怎么选择呢?
RDB的快照文件本质是二进制文件，其体积比较小，而AOF文件需要保存redis中的写操作指令，在体积上比较大，所以在恢复速度上RDb比较快，但是RDB存在数据丢失的风险，在我的项目中只要主要还是使用AOF，像支付方式模板这种比较重要的数据，我们应当降低其丢失的风险，在刷盘策略上使用每秒进行一次刷盘，也就是每秒批量写入一次。
问：redis的key过期后，会立刻做删除操作吗?
redis有两种数据过期策略，分别是惰性删除和定期删除。
惰性删除：我们会为每个key设置一个过期时间，在每次获取数据的时候会先去判断该key是否过期，如果过期直接删除key，如果没有过期则直接返回，也就是说在没有使用数据时不会主动删除。（优点：对CPU友好，只在查询时才做过期判断。缺点：内存消耗大。）
定期删除：定期去判断一定数量的key是否过期，如果过期则直接进行删除操作，定期删除又分为SLOW模式和FAST模式。（优点：内存消耗小。缺点：定期查询key需要消耗大量时间。）
SLOW模式：默认的频率为10hz（一秒内进行十次），每次不大于25ms，我们可以通过配置文件中的hz修改频率。
FAST模式：执行频率是不固定的，两次删除的间隔不小于2ms，每次耗时小于1ms。
redis默认采用的数据过期删除策略：惰性删除+定期删除配合使用。
问：假如缓存过多，内存有限，内存满了怎么办呢?
在redis中提供了八种数据淘汰的策略，那默认的处理就是noeviction，就是直接报错。我们可以提供配置文件修改对应的淘汰策略。策略中有两种重要的思想，分别是LRU和LFU。
LRU:就是将当前使用间距最长的数据进行淘汰。（对应两个）
LFU:就是将当前使用频率最少的数据进行淘汰。（对应两个）
随机淘汰策略。
八个策略的不同就在于key的类型(全部key和设置过期时间的key)和使用的思想不同(LRU和LFU)。
在我的项目中主要使用的淘汰策略就是: allkey-lru,淘汰掉当前使用最少的数据。
问：数据库中有100w条数据，redis只能存储20w数据，如何保证redis中的数据是热点数据呢?
使用 allkey-lru策略，保证经常使用的数据不被淘汰。
问：redis缓存的空间用完了会怎么样？
如果是默认情况下的话，会直接报错，因为默认的淘汰策略就是noeviction，如果设置了其他的策略则会对数据进行淘汰。
问：能介绍一下redis的主从复制和主从复制的流程吗?
单个redis节点的并发能力是有限的，所以为了提高并发能力，我们需要搭建redis集群，就比如：主从复制。
主从复制的流程
主从复制主要分为：全量同步和增量同步。
全量同步：在salve请求数据同步的时候会携带application Id和offset，如果master判断出applid和自己的不一样，就认为slave是第一次进行同步，所以会进行全量同步。 master会执行bgsave生成RDB文件给slave，slave进行同步，在此过程中master可能会进行新的指令，master会将这些指令存储到日志文件，在加载RDB完后再将日志文件传给slave进行最终的同步，master同步applid和offset给slave。
增量同步： 在master判断出slave中的applid和自己一样就认为不是第一次同步，直接进行增量同步，从日志文件中获取到offset的位置，将offset之后的数据发送给slave，进行数据的同步。
问：那主节点宕机了又该怎么办呢？
为了提高redis集群的高可用，我们可以使用哨兵模式，解决主节点宕机的问题。
问：那说说你对哨兵模式的理解吧
哨兵模式：通过sentinel的心跳机制去监测master的状态，当然为了保证高可用，我们也需要对sentinel搭建集群。sentinel每隔1秒就会向集群的节点发送ping指令，当master失效后会就选择出新的master。
在sentinel中有两种概念：主观下线和客观下线。
主观下线：当有一个sentinel发现redis节点没有返回响应就认为其为主观下线。
客观下线：当有一半以上的sentinel节点发现redis节点没有返回响应就认为其为客观下线。
当master发生客观下线就会筛选slave作为新的master。
筛洗新master的优先级为下：
1.判断master与slave断开的时长，如果时长超过指指定值则直接排除。
2.判断slave的权重，如果权重越小优先级就越高。
3.如果权重相同的话，就比较slave的offst值也就是偏移量，如果offset越大优先级就越高。
4.判断slave运行id的大小，如果运行id越小则优先级越高。
问：哨兵模式可能会出现脑裂的情况，有了解过吗？
由于网络不稳定的因素，多个sentinel都没有ping到master，此时master是没有宕机的，而哨兵模式就会选择出新的master，就出现两个master的情况，而客户还是对旧的master进行数据的操作，在网络稳定后，旧的master就会变成新master的slave，最终导致数据操作的丢失。从而形成脑裂的现象。
解决脑裂的方案：
1.在redis的配置文件中设置最少的slave个数（对应的配置项:min-replicas-to-write）。当出现脑裂的情况时，旧的master会监测到没有slave，就不会做数据的操作直接返回错误信息，防止数据操作的丢失。
2.在resdis的配置文件中设置最大数据同步的延迟时间。（对应的配置项:min-replicas-max-lag）。当出现脑裂的情况时。旧的master在做数据的同步时一直找不到slave，当时间超过最大的延迟时间就会直接返回错误信息，防止数据操作的的丢失。
问：你们使用redis是单点还是集群？
我们的redis使用主从模式（一主一从）+ 哨兵模式。当然在容量不够的时候，会为不同的服务配置独立的redis主从节点。
问：redis分片集群有什么作用？
1,存在多个master,这些master存储不同的数据，多个master可以解决并发写的问题。
2.每一个master都可以有多个slave，解决并发读的问题。
3.在分片集群中，不再通过sentinel监测master的健康状态，而是通过master之间ping状态，判断各个master的健康状态，最终达到哨兵模式的效果。
4.客户端在访问对应的数据时会路由到对应的节点上。
问:redis分集群中的数据是如何存储和读取的呢？
redis分片集群采用的是哈希槽的结构实现的，哈希槽总共有16384个。master节点等量的获取哈希槽范围用于存储数据。
在存储数据的时候，通过有效部分取哈希槽总数的模计算出哈希值（这里的有效部分指key前大括号中的有效值（就比如: set {}key value），如果没有大括号key就是有效部分），找到master后做写操作。
在读数据的时候，通过计算出的哈希值确定存储数据的master位置，从该master对应的slave中读取数据，到达读写分离的效果。
问：redis是单线程的，为什么会那么快呢?
1.完全基于内存的，是C语言编写的。
2.采用单线程，避免了不必要的上下文切换可竞争条件，多线程还需要考虑线程问题。
3.采用多路IO复用模型，非阻塞IO模型。
问：说说对阻塞IO和非阻塞IO的理解吧。
我们先需要知道内存的使用情况为：用户空间和内核空间。
用户空间：只能执行受限制的指令，不能直接调用系统资源，需要通过内核提供的接口来调用系统资源。
内核空间：可以执行特权指令，可以直接调用系统资源。
阻塞IO:在用户线程要获取内核中获取数据，而此时内核中没有数据，用户线程就会等待从而导致用户线程阻塞，当内核中有数据后，数据需要重内核缓冲区复制到用户缓冲区，在这个过程中用户线程也需要等待从而导致线程堵塞。在这两个阶段中用户线程都是堵塞的，这就是堵塞IO。
非堵塞IO: 用户线程要从内核中获取数据，但内核中没有数据，此时内核直接返回错误信息给用户线程，反之线程堵塞，用户线程会循环的调用内核的方法直到内核中有数据，当内核中有数据后，用户线程就会等待内核缓冲区中的数据复制到用户缓冲区中，此时用户线程是阻塞的。在第一阶段是不阻塞的，而第二阶段是堵塞的，这就是非堵塞IO。比阻塞IO优化没多少，而且忙等机制可能会导致CPU的空转，CUP使用率暴增。
问：解释一下什么是多路IO复用模型？
单线程同时监听多个Socket（操作客户端）的状态，某个Socket可读可写时得到通知，防止出现忙等的情况，提高CPU的利用率，可能同时存在多个可用Socket，通过循环做读取数据的操作，多路IO复用主要通过epoll模式实现的，将已就绪的socket存到用户空间中，就不需要遍历判断socket是否就绪，从而提高性能。
问：有了解过redis的网络模型吗？
最低0.47元/天 解锁文章
扫一扫
29万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
