全程面试30min，感觉还行，聊得比较愉快。          1.自我介绍       2.问我如何获取java知识？       主要是从书中和技术官网，然后就是找一些视频，在途中遇到问题会去搜一些技术博客之类的。       3.自己看的书里面哪些印象比较深？       《MySQL技术内幕》《深入理解Java虚拟机》《Java并发编程之美》主要讲了深入理解Java虚拟机里的垃圾回收器，线程安全和锁的升级过程。       垃圾回收器       jdk1.7 默认垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）       jdk1.8 默认垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）       jdk1.9 默认垃圾收集器G1       主要讲一下G1，G1摒弃了分代的概念，把连续的Java堆划分为多个大小相等的独立区域，每一个Region都可以根据需要，扮演新生代的Eden空间,Survivor空间，或者老年代。每次回收优先处理回收价值最大的那些Region。可以控制stw，基于标记整理...balabala一顿说。       4.说说深入理解jvm这本书你的收获？       在看第二章的时候在OOM那块，收获就是在有些代码里需要注意一些边界条件，比如递归的时候避免Stack Overflow之类的，避免在死循环里一直new对象等。       5.线程池的相关问题？       线程池的核心参数有哪些，其中有些参数需要根据实际的业务场景去选择。       1.corePoolSize：核心线程数       核心线程会一直存活，及时没有任务需要执行。       当线程数小于核心线程数时，即使有线程空闲，线程池也会优先创建新线程处理。       设置allowCoreThreadTimeout=true（默认false）时，核心线程会超时关闭。       2.queueCapacity：任务队列容量（阻塞队列）       当核心线程数达到最大时，新任务会放在队列中排队等待执行。       3.maxPoolSize：最大线程数       当线程数>=corePoolSize，且任务队列已满时。线程池会创建新线程来处理任务。       当线程数=maxPoolSize，且任务队列已满时，线程池会拒绝处理任务而抛出异常。       4.keepAliveTime：线程空闲时间       当线程空闲时间达到keepAliveTime时，线程会退出，直到线程数量=corePoolSize。       如果allowCoreThreadTimeout=true，则会直到线程数量=0。       5.allowCoreThreadTimeout：允许核心线程超时       6.rejectedExecutionHandler：任务拒绝处理器       两种情况会拒绝处理任务：(1)当线程数已经达到maxPoolSize，切队列已满，会拒绝新任务。(2)当线程池被调用shutdown()后，会等待线程池里的任务执行完毕，再shutdown。如果在调用shutdown()和线程池真正shutdown之间提交任务，会拒绝新任务。线程池会调用rejectedExecutionHandler来处理这个任务。如果没有设置默认是AbortPolicy，会抛出异常。       ThreadPoolExecutor类有几个内部实现类来处理这类情况：(1)AbortPolicy 丢弃任务，抛运行时异常。(2)CallerRunsPolicy 执行任务。(3)DiscardPolicy 忽视，什么都不会发生。(4)DiscardOldestPolicy 从队列中踢出最先进入队列（最后一个执行）的任务。实现RejectedExecutionHandler接口，也可自定义处理器。       线程执行顺序                当线程数小于核心线程数时，会一直创建线程直到线程数等于核心线程数；                   当线程数等于核心线程数时，新加入的任务会被放到任务队列等待执行；                   当任务队列已满，又有新的任务时，会创建线程直到线程数量等于最大线程数；                   当线程数等于最大线程数，且任务队列已满时，新加入任务会被拒绝。              6.spring解决循环依赖问题为什么使用三级缓存？       跟面试官说因为spring的设计理念😂😂😂       7.redis的使用场景       先说说自己项目里是如何使用的，然后在说一下redis的使用场景。       8.redis的缓存一致性问题       经典问题           （1）先删缓存，再更新数据库          先删除缓存，数据库还没有更新成功，此时如果读取缓存，缓存不存在，去数据库中读取到的是旧值，缓存不一致发生。          解决方案：延时双删，延时双删的方案的思路是，为了避免更新数据库的时候，其他线程从缓存中读取不到数据，就在更新完数据库之后，再sleep一段时间，然后再次删除缓存。sleep的时间要对业务读写缓存的时间做出评估，sleep时间大于读写缓存的时间即可。流程如下：线程1删除缓存，然后去更新数据库线程2来读缓存，发现缓存已经被删除，所以直接从数据库中读取，这时候由于线程1还没有更新完成，所以读到的是旧值，然后把旧值写入缓存线程1，根据估算的时间，sleep，由于sleep的时间大于线程2读数据+写缓存的时间，所以缓存被再次删除如果还有其他线程来读取缓存的话，就会再次从数据库中读取到最新值          （2）先更新数据库，再删除缓存          这个就更明显的问题了，更新数据库成功，如果删除缓存失败或者还没有来得及删除，那么，其他线程从缓存中读取到的就是旧值，还是会发生不一致。解决方案消息队列先更新数据库，成功后往消息队列发消息，消费到消息后再删除缓存，借助消息队列的重试机制来实现，达到最终一致性的效果。这个解决方案其实问题更多。          引入消息中间件之后，问题更复杂了，怎么保证消息不丢失更麻烦就算更新数据库和删除缓存都没有发生问题，消息的延迟也会带来短暂的不一致性，不过这个延迟相对来说还是可以接受的进阶版消息队列为了解决缓存一致性的问题单独引入一个消息队列，太复杂了。          其实，一般大公司本身都会有监听binlog消息的消息队列存在，主要是为了做一些核对的工作。          这样，我们可以借助监听binlog的消息队列来做删除缓存的操作。这样做的好处是，不用你自己引入，侵入到你的业务代码中，中间件帮你做了解耦，同时，中间件的这个东西本身就保证了高可用。当然，这样消息延迟的问题依然存在，但是相比单纯引入消息队列的做法更好一点。而且，如果并发不是特别高的话，这种做法的实时性和一致性都还算可以接受的。          9.问项目里的微服务都有哪些？       10.在项目中遇到的问题               总结：面试体验不错，期待二面。关于上文提到的问题，欢迎大家评论区一起交流讨论。