京东Java面试题及答案.docxVIP

京东Java面试题及答案

一、Java基础核心

问：volatile关键字有什么用？实际开发中你在哪用过？

答：主要保证可见性和禁止指令重排序，但不保证原子性。比如京东商品库存更新场景，用volatile修饰库存变量，能让线程修改后立刻同步到主内存，避免其他线程读旧值；还有双重检查单例模式里，volatile能防止instance初始化时的指令重排（比如先赋值地址再初始化对象），避免拿到半初始化的实例。

问：HashMap和ConcurrentHashMap的区别？JDK1.8里ConcurrentHashMap做了哪些优化？

答：HashMap线程不安全，并发下会有死循环（1.7链表）或数据覆盖问题；ConcurrentHashMap是线程安全的。1.8的优化主要是：①放弃分段锁，改用CAS+synchronized锁链表头/红黑树根节点，锁粒度更细，并发效率更高；②底层结构和HashMap一致，都是数组+链表+红黑树，当链表长度超8会转树；③支持原子操作如putIfAbsent，不用自己加锁判断。比如京东购物车缓存，用ConcurrentHashMap存用户购物车数据，既能保证线程安全，又比Hashtable效率高。

问：Java内存模型（JMM）里，线程间怎么通信？为什么会有可见性问题？

答：线程通信有两种：共享内存（通过读写字段）和消息传递（如wait/notify），JMM用共享内存模型。可见性问题源于CPU缓存和指令重排——线程读数据会先放缓存，修改后没及时刷回主内存，其他线程就看不到；比如京东订单状态更新，线程A改了订单状态存在缓存，线程B读主内存旧状态，就会导致订单状态不一致。

二、高并发与分布式

问：线程池参数怎么设置？比如京东秒杀场景，核心线程数和最大线程数该怎么配？

答：核心参数要结合业务类型：CPU密集型（如订单计算）核心线程数设为CPU核心数±1，避免上下文切换；IO密集型（如查DB、调用第三方接口）设为CPU核心数×2，因为线程大部分时间在等IO。秒杀场景特殊：①核心线程数设小（比如CPU核心数×1），避免平时空耗资源；②最大线程数不能太大（比如200），防止线程太多导致CPU过载；③队列用SynchronousQueue，让任务直接交给线程，避免队列堆积；④拒绝策略用自定义的，比如秒杀时返回“活动太火爆，请重试”，而不是抛异常。

问：分布式事务怎么解决？京东订单下单时，订单创建和库存扣减怎么保证一致性？

答：常用方案有TCC、SAGA、本地消息表、Seata。京东订单场景用TCC比较多：①Try阶段：订单预创建（状态为“待确认”）、库存预扣减（冻结部分库存）；②Confirm阶段：如果Try都成功，订单改“已创建”、库存正式扣减；③Cancel阶段：如果某一步失败，订单回滚删除、库存解冻。比2PC更适合电商高并发，因为TCC无锁且异步，不会阻塞。

问：Redis缓存穿透、击穿、雪崩怎么解决？京东商品详情页怎么防这些问题？

答：①穿透：查不存在的key，比如恶意查商品ID=-1，用布隆过滤器提前过滤不存在的ID，或者缓存空值（设短过期时间，比如5分钟）；②击穿：热点key过期瞬间大量请求打DB，比如某爆款商品key过期，用互斥锁（Redis的setIfAbsent），只让一个线程去DB查并更新缓存，其他线程等重试；③雪崩：大量key同时过期，比如凌晨3点缓存批量失效，给key加随机过期时间（比如基础1小时+0-30分钟随机），避免集中过期。京东商品详情页这三种方案都用了，还加了本地缓存（Caffeine），进一步抗并发。

三、框架与中间件

问：SpringBean的生命周期？循环依赖怎么解决的？

答：生命周期大概是：实例化（new对象）→属性注入（@Autowired）→初始化（InitializingBean的afterPropertiesSet、@PostConstruct）→使用→销毁（DisposableBean的destroy、@PreDestroy）。循环依赖比如A依赖B，B依赖A，Spring用三级缓存解决：①一级缓存存完整Bean；②二级缓存存刚实例化未注入属性的Bean；③三级缓存存Bean的工厂方法。当A实例化后，把A的工厂放三级缓存，注入B时发现B依赖A，就从三级缓存取A的工厂生成A的早期Bean（未注入属性），放二级缓存给B注入，B实例化完再给A注入，最后A