Java面试题

1.redis key删除策略
　　定期删除：贪心策略
　　　　1.从过期字典中随机 20 个 key；
　　　　2.删除这 20 个 key 中已经过期的 key；
　　　　3.如果过期的 key 比率超过 1/4，那就重复步骤 1；
　　惰性删除：
　　　　在客户端访问这个key的时候，redis对key的过期时间进行检查，如果过期了就立即删除，不会给你返回任何东西。

　　定期删除是集中处理，惰性删除是零散处理。

3.es 为什么这么快，分词的原理，分页优化

4.配置加载顺序优先级
　　bootstrap.yml在项目启动时，就会加载
　　application.yml在springContext加载后进行加载
5.springboot常用注解
　　@SpringBootApplication 包含 @SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan
　　@ImportResource @Scope @Primary @Lazy @Profile
6.数据库数据发生变化，如何同步给Redis
　　方案1：直接删除Redis缓存；
　　方案2: 基于MQ异步同步更新
　　方案3： 基于canal订阅binlog同步
7.项目高并发解决方案
　　非垂直拆分，水平拆分
　　垂直拆分的话就是，增加服务器节点，消耗成本，升级CPU
　　水平拆分的话包括
　　　　前端页面静态化
　　缓存：浏览器缓存 -> CDN加速 -> Nginx动静分离，Nginx缓存 -> Redis缓存 -> DB
　　应用拆分，分布式开发，业务拆分
　　数据库拆分：垂直拆分和水平拆分
　　数据库连接池、Redis连接池、线程池、消息队列
　　采用数据搜索引擎
　　JVM参数优化
8.秒杀项目会有的问题
　　1.商品超卖
　　2.高并发
　　　　页面优化，线程池、mq、信号量限制
　　3.重复下单
　　4.秒杀地址暴露
　　5.分布式事务

9.数据库系统的负载均衡
　　多主、一主一从、一主多从、多级主从
10.项目并发量，多线程的应用场景
　　高并发系统的本质就是充分利用硬件资源，提升cpu
11.mysql 分库分表利弊
　　多主、一主一从、一主多从、多级主从
　　缺点：
　　　　分布式事务、
　　关联查询 join、排序、函数 问题、
　　分布式ID问题、
　　数据迁移、扩容问题

12.你们项⽬如何排查JVM问题
　　对于还在正常运⾏的系统：
　　1.可以使⽤jmap来查看JVM中各个区域的使⽤情况
　　2.可以通过jstack来查看线程的运⾏情况，⽐如哪些线程阻塞、 是否出现了死锁
　　3.可以通过jstat命令来查看垃圾回收的情况，特别是fullgc，如果发现fullgc⽐较频繁，那么就得进⾏调优了
　　4.通过各个命令的结果，或者jvisualvm等⼯具来进⾏分析
　　5.⾸先，初步猜测频繁发送fullgc的原因，如果频繁发⽣fullgc但是⼜⼀直没有出现内存溢出，那么表示fullgc实际上是回收了很多对象了，所以这些对象最好能在younggc过程中就直接回收掉，避免这些对 象进⼊到⽼年代，对于这种情况，就要考虑这些存活时间不⻓的对象是不是⽐较⼤，导致年轻代放不 下，直接进⼊到了⽼年代，尝试加⼤年轻代的⼤⼩，如果改完之后，fullgc减少，则证明修改有效
　　6.同时，还可以找到占⽤CPU最多的线程，定位到具体的⽅法，优化这个⽅法的执⾏，看是否能避免某些 对象的创建，从⽽节省内存

13.对于已经发⽣了OOM的系统：
　　1.⼀般⽣产系统中都会设置当系统发⽣了OOM时，⽣成当时的dump⽂件（- XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/base）
　　2.我们可以利⽤jsisualvm等⼯具来分析dump⽂件
　　3.根据dump⽂件找到异常的实例对象，和异常的线程（占⽤CPU⾼），定位到具体的代码
　　4.然后再进⾏详细的分析和调试

　　总之，调优不是⼀蹴⽽就的，需要分析、 推理、 实践、 总结、 再分析，最终定位到具体的问题

14.Java死锁如何避免？
　　造成死锁的⼏个原因：
　　1.⼀个资源每次只能被⼀个线程使⽤
　　2.⼀个线程在等待时，不释放已占有资源
　　3.⼀个线程已经获得的资源，在未使⽤完之前，不能被强⾏剥夺
　　4.若⼲线程形成头尾相接的循环等待资源关系

　　这是造成死锁必须要达到的4个条件，如果要避免死锁，只需要不满⾜其中某⼀个条件即可。 ⽽其中前3个条件是作为锁要符合的条件，所以要避免死锁就需要打破第4个条件，不出现循环等待锁的关系。

　　在开发过程中：
　　　　1.要注意加锁顺序，保证每个线程按同样的顺序进⾏加锁
　　　　2.要注意加锁时限，可以针对所设置⼀个超时时间
　　　　3.要注意死锁检查，这是⼀种预防机制，确保在第⼀时间发现死锁并进⾏解决

15.消息队列如何保证消息可靠传输
　　消息可靠传输代表了两层意思，既不能多也不能少。
　　1.为了保证消息不能多，也就是消息不能重复
　　　　a.⾸先要确保消息不多发，这个不常出现，也⽐较难控制，因为如果出现了多发，很⼤的原因是⽣产 者⾃⼰的原因，如果要避免出现问题，就需要在消费端做控制
　　　　b.要避免不重复消费，最保险的机制就是消费者实现幂等性，保证就算重复消费，也不会有问题，通 过幂等性，也能解决⽣产者重复发送消息的问题
　　2.消息不能少，意思就是消息不能丢失
　　　　a.⽣产者发送消息时，要确认消息投递成功，⽐如RabbitMQ的transaction机制和confirm机制，Kafka的ack机制都可以保证⽣产者能正确的将消息发送给broker
　　　　b.broker：确认broker确实收到并持久化了这条消息，将队列的持久化标识durable设置为true
　　　　c.消费端手动ack机制，消费者接收到⼀条消息后，如果确认没问题了，就可以给broker发送⼀个ack，broker接收到ack后才会删除消息

16.消息堆积的解决方案
　　1、消息发送的速率远远大于消息消费的速率。
　　　　通过关闭某些不重要的业务，减少发送的数据量
　　2、消费者出现了问题，导致无法消费。
　　　　a.先修改consumer的问题，确保其恢复消费速度
　　　　b.临时启用多个消费者，通过扩容消费端的实例数来提升总体的消费能力。
　　　　c.消费者参数优化，在初始化的时候提高并发消费者的个数

17.合适的线程数量是多少？CPU 核心数和线程数的关系？
　　线程数 = CPU 核心数 *（1+平均等待时间/平均工作时间）

18. 如何让你来设计消息队列中间件，如何设计？
　　1、MQ得支持可伸缩性
　　2、就是需要的时候增加吞吐量和容量？
　　3、考虑MQ的数据持久化
　　4、考虑MQ的可用性。
19. 如何保证消息的顺序性
　　a. 使用单线程消费来保证消息的顺序性，保证生产者 - MQServer - 消费者是一对一对一的关系
　　b. 对消息进行编号，消费者处理时根据编号来判断顺序

20. 什么是沾包拆包
　　TCP以流方式传输，是没有界限的一串数据，并没有消息边界。
　　　　- TCP传输数据时，会根据底层的TCP缓存区实际情况进行数据包划分：
　　　　- 1.业务上定义的完整数据(比方说一个完整的json串)，可能会被TCP拆分成多个数据包进行发送(拆包)。
　　　　- 2.业务上特殊含义的独立数据，也有可能因为大小或者缓冲区原因，被TCP封装成一个大数据包发送(粘包)。
21. 怎么解决沾包拆包问题
　　1.在发送端每个数据包首部添加数据包长度字段，在接收端接收到消息后，通过读取首部的长度字段，便可知道数据包的实际长度了
　　2.发送端的每个数据包封装为固定长度（不够的部分补0填充），这样接收端就自然而然的把每个数据包拆分开
　　3.设置数据包之间的边界，如设置特殊符号

22. 一般不建议使用System.gc，为什么还要有这个方法
　　一般不建议使用system.gc()去显示地要求进行垃圾回收，一般每一次显示的调用system.gc()都会进行一次full gc,而full gc会导致应用的暂停，如果频繁地full gc会导致应用长时间暂停，也就无法正常运行了。

23. mysql数据库删除重复的数据保留一条
　　解答一：
　　　　delete from Person where Id not in (
　　　　　　select t.min_id from ( select min(Id) as min_id from Person group by Email) as t );

　　解答二：
　　　　delete p1 from Person as p1,Person as p2 where p1.Email=p2.Email and p1.Id > p2.Id;