哔哩哔哩Java后端高频面试题及详细答案（真实面试版）

哔哩哔哩Java后端高频面试题及详细答案（真实面试版）本套题目整理自B站历年校招、社招、实习真实面试场景，聚焦后端核心考点，答案采用程序员日常面试口语化表述，贴合面试官考核标准，规避书面模板化话术，覆盖基础、集合、JVM、多线程、数据库、框架、实战场景全模块。一、Java基础核心（B站必问基础考点）1、String、StringBuilder、StringBuffer的区别？日常开发怎么选型？三者核心差异集中在可变性、线程安全、性能三个维度。首先是可变性，String是不可变字符串，JDK9之前底层是final修饰的char数组，JDK9及之后改成byte数组，一旦赋值不能修改，每次拼接、修改都会生成新对象；而StringBuilder和StringBuffer底层没有final修饰，属于可变字符串，修改操作直接操作原对象，不会频繁创建新实例。然后是线程安全，StringBuffer所有修改方法都加了synchronized锁，多线程环境下安全，但加锁会带来性能损耗；StringBuilder没有加锁，线程不安全，但是执行效率最高；String不可变，天然线程安全。最后是选型：单线程场景下优先用StringBuilder，性能最好；多线程字符串拼接场景用StringBuffer；字符串内容固定、频繁查询、作为常量参数时直接用String。2、==和equals()的区别？重写equals为什么必须重写hashCode()？==是运算符，既可以比较基本数据类型，也可以比较引用数据类型。基本类型比较的是数值本身，引用类型比较的是对象的内存地址。equals()是Object类的方法，默认实现和==一致，也是比较对象地址。大部分业务类（String、Integer）都会重写该方法，重写后是比较对象的内容、属性值，不再比较地址。重写equals必须重写hashCode的核心原因是遵守哈希表存储规范。如果只重写equals，两个内容相同的对象，equals判断相等，但默认hashCode基于地址生成，会得到不同哈希值。在HashMap、HashSet中，会判定这是两个不同对象，造成内容相同的对象重复存储，出现逻辑bug。重写后能保证：equals相等的对象，hashCode一定相等。3、final、finally、finalize的区别？三个单词只是拼写相近，功能完全无关。final是修饰符，可以修饰类、方法、变量。修饰类表示类不能被继承；修饰方法表示方法不能被重写；修饰变量表示变量不可修改，基本类型数值固定，引用类型地址固定。finally是异常处理代码块，搭配try-catch使用，无论代码正常执行还是抛出异常，finally代码块都会执行，常用于关闭流、释放连接等资源回收操作。唯一不执行的场景是手动执行System.exit()退出程序。finalize()是Object类的废弃方法，JDK9之后彻底废弃。原本作用是GC回收对象前触发，用于自定义资源释放，但执行时机不确定、无法保证执行，容易导致资源泄漏，日常开发完全不用。二、Java集合框架（B站面试高频重点）1、HashMapJDK1.7和JDK1.8的核心区别？为什么要做优化？HashMap是B站面试集合模块的必考考点，两个版本核心优化围绕解决哈希冲突、提升查询效率展开。第一是数据结构，JDK1.7只有数组+单向链表，所有哈希冲突的元素都挂在链表上，链表过长后查询时间复杂度是O(n)，效率极低；JDK1.8改成数组+链表+红黑树，当链表长度超过8且数组容量大于64时，链表会转为红黑树，查询复杂度降到O(logn)，大幅优化长链表查询性能。第二是插入方式，1.7是头插法，新元素插入链表头部，多线程扩容时容易出现链表环形引用，引发死循环；1.8改成尾插法，保留原有节点顺序，彻底解决扩容死循环问题。第三是扩容优化，1.7扩容需要重新计算所有元素的哈希位置；1.8优化了哈希迁移逻辑，元素要么留在原位置，要么偏移原容量位置，无需重复计算哈希，效率更高。2、HashMap的扩容机制？默认容量、负载因子为什么是16和0.75？HashMap默认初始容量是16，默认负载因子0.75，扩容阈值=容量*负载因子，也就是容量达到12时触发第一次扩容，每次扩容为原容量的2倍，保证容量始终是2的幂次。选用2的幂次容量，是为了优化哈希取模运算，用位运算替代取模，速度更快；同时能让元素分布更均匀，减少哈希冲突。负载因子设置0.75是平衡空间和时间效率。如果负载因子太大，比如1，数组填满才扩容，哈希冲突概率极高，链表、树结构变多，查询变慢；如果负载因子太小，比如0.5，频繁扩容，浪费内存空间、消耗扩容性能，0.75是官方实测最优平衡点。3、HashMap和ConcurrentHashMap的区别？线程安全原理？HashMap是非线程安全的，多线程put、扩容时会出现数据覆盖、链表死循环、数据丢失等问题，只适用于单线程场景。ConcurrentHashMap是线程安全的哈希集合，专门用于多线程环境，性能远优于HashTable。JDK1.7的ConcurrentHashMap采用分段锁机制，将数组分成16个分段，每个分段独立加锁，不同分段可以并发操作，大幅提升并发量；JDK1.8废弃分段锁，采用CAS+synchronized锁，只锁住当前链表/树的头节点，锁粒度更细，并发性能更强，同时保留数组+链表+红黑树结构。三、JVM核心知识点（B站中高级面试必问）1、JVM内存区域划分？各区域的作用和OOM场景？JVM运行时内存分为五大区域，其中线程私有区：程序计数器、虚拟机栈、本地方法栈；线程共享区：堆、方法区。程序计数器：记录当前线程执行的字节码行号，是唯一没有OOM异常的内存区域。虚拟机栈：存储局部变量、方法栈帧、操作数栈，方法调用和执行都依赖该区域。栈深度过大出现StackOverflowError，线程栈内存不足会抛出OOM。本地方法栈：作用和虚拟机栈类似，专门为native本地方法服务，同样会出现栈溢出和OOM。堆：JVM最大内存区域，所有对象实例、数组都在堆中分配，也是GC的主要回收区域。堆内存不足、对象无法回收时，抛出堆内存OOM，日常开发最常见。方法区：存储类信息、常量、静态变量、编译后的代码缓存。JDK1.8后用元空间替代永久代，元空间使用本地内存，默认不受JVM堆限制，只有加载过多类、动态生成类时会触发元空间OOM。2、CMS和G1垃圾收集器的区别？线上环境怎么选型？CMS和G1是生产环境最常用的两款垃圾收集器，核心差异是设计目标、内存模型、垃圾回收方式不同。CMS是针对老年代的收集器，采用标记-清除算法，主打低延迟、减少STW（stop-the-world）。优点是并发回收，用户线程和GC线程并行执行，停顿时间短；缺点是会产生内存碎片，需要定期整理内存，且无法处理浮动垃圾，并发阶段容易出现ConcurrentModeFailure，触发降级GC。G1是一款面向全堆的收集器，将堆内存划分为多个大小相等的区域，可同时回收年轻代和老年代。核心优势是可预测停顿时间，能手动设置最大停顿阈值，优先回收垃圾最多的区域，内存碎片少。缺点是内存开销、CPU占用比CMS高。线上选型：低延迟、追求极致响应速度的业务（短视频、直播接口，贴合B站业务场景）优先G1；老旧项目、内存较小、CPU资源有限的服务用CMS。3、线上出现OOM怎么排查？完整排查流程？线上OOM排查不要直接加大堆内存，标准排查流程分四步，是B站后端面试高频实操题。第一步：查看日志，确定OOM类型，区分是堆内存溢出、元空间溢出、栈溢出还是直接内存溢出，定位问题范围。第二步：使用jps定位异常进程号，通过jmap命令导出堆快照文件，或者开启JVM参数自动导出dump文件，保留现场数据。第三步：用MAT、JProfiler分析dump文件，查看大对象、常驻对象、对象引用链，定位是否存在内存泄漏，比如未关闭的连接、静态集合无限累积对象、循环引用等。第四步：结合arthas在线监控，查看线程状态、GC频率、内存占用，定位代码层级问题，修复后压测验证，避免问题复发。四、多线程与并发编程（核心高频）1、线程池核心参数？七大参数、四种拒绝策略、工作原理？线程池核心七大参数：核心线程数、最大线程数、空闲线程存活时间、时间单位、任务队列、线程工厂、拒绝策略。工作流程：提交任务后，首先判断核心线程数是否已满，未满则创建核心线程执行任务；核心线程已满，任务进入阻塞队列；队列满了，创建非核心线程执行任务；线程数达到最大值，触发拒绝策略。四种拒绝策略：AbortPolicy直接抛异常（默认）；CallerRunsPolicy由调用者线程执行任务，不抛弃任务；DiscardPolicy直接丢弃当前新任务，不报错；DiscardOldestPolicy丢弃队列最旧任务，执行新任务。2、newFixedThreadPool、newCachedThreadPool区别？生产为什么不推荐用Executors创建线程池？newFixedThreadPool是固定线程池，核心线程数和最大线程数一致，线程数量固定，队列无界，适合任务量大、耗时稳定的业务，缺点是任务堆积过多会造成内存溢出。newCachedThreadPool是缓存线程池，核心线程数为0，最大线程数无限，线程空闲60秒自动回收，适合大量短时任务，缺点是高并发下会创建无限多线程，导致CPU爆满、线程溢出。生产不推荐Executors的核心原因：封装好的线程池要么队列无界，要么线程数无界，极端场景下极易出现OOM、线程耗尽问题。生产必须手动通过ThreadPoolExecutor自定义线程池，根据业务设置合理参数和拒绝策略。3、synchronized和Lock的区别？第一，底层实现不同，synchronized是JVM底层原生锁，基于对象头监视器实现，隐式加锁解锁；Lock是Java代码层面的锁，是接口，需要手动调用lock()、unlock()加锁解锁。第二，锁特性不同，synchronized是悲观锁、可重入、不可中断、非公平锁；Lock支持可重入、可中断、可公平/非公平切换，还能绑定多个条件变量，精准唤醒线程。第三，性能差异，JDK1.6之后synchronized引入偏向锁、轻量级锁、自旋锁优化，性能大幅提升，和Lock基本持平。低并发场景synchronized更简洁，高并发、需要精细化锁控制场景用Lock。五、MySQL数据库（B站业务高频考点）1、事务ACID特性？脏读、不可重复读、幻读区别及解决办法？事务四大特性：原子性、一致性、隔离性、持久性。原子性是事务要么全部成功、要么全部回滚；一致性是事务前后数据完整性一致；隔离性是多事务并发互不干扰；持久性是事务提交后数据永久落地。脏读：一个事务读取到另一个事务未提交的脏数据，对方回滚后数据失效。不可重复读：同一事务内，多次查询同一数据，结果不一致，因为其他事务修改并提交了数据。幻读：同一事务内，多次查询数据行数不一致，其他事务新增、删除了数据，像出现幻觉一样。隔离级别解决：读已提交解决脏读；可重复读解决脏读、不可重复读（MySQL默认级别）；串行化彻底解决三大问题，但并发性能最低。2、InnoDB索引结构？B+树为什么比B树、哈希索引适合MySQL？InnoDB索引底层是B+树结构，所有数据都存在叶子节点，非叶子节点只存索引键，不存数据。对比B树：B树每个节点都存数据，单次查询IO次数更多；B+树非叶子节点轻量化，树高度更低，查询更快，且所有叶子节点有序链表，适合范围查询、排序、分页，贴合业务查询场景。对比哈希索引：哈希索引等值查询快，但不支持范围查询、排序、模糊查询，且存在哈希冲突；B+树适配所有常用查询场景，稳定性更强，是InnoDB默认索引结构。3、慢SQL优化的完整思路？第一步：通过慢查询日志、explain分析SQL执行计划，定位问题，重点看是否走索引、索引失效、全表扫描、临时表、文件排序。第二步：索引优化，避免索引失效，比如不使用select*、避免字段隐式转换、like不以%开头、or条件字段全部建索引。第三步：SQL语句优化，拆分复杂关联查询、避免大表join、分页深翻用延迟查询、批量操作拆分批次。第四步：架构优化，大表分库分表、读写分离、热点数据缓存，减轻数据库压力。六、Spring框架高频考点1、SpringBean的生命周期？完整生命周期分为6个核心步骤，流程清晰：1.实例化：Spring容器通过反射创建Bean实例；2.属性填充：自动装配依赖属性，完成DI依赖注入；3.Aware接口回调：执行BeanNameAware、BeanFactoryAware等接口方法，获取容器资源；4.前置处理：BeanPostProcessor前置后置处理，对Bean做增强；5.初始化：执行@PostConstruct、afterPropertiesSet、自定义init方法；6.销毁：容器关闭时，执行@PreDestroy、自定义destroy方法释放资源。2、SpringController是单例还是多例？有什么线程安全问题？怎么解决？SpringController默认是单例Bean，整个容器中只有一个实例。线程安全问题：单例模式下，成员变量会被所有请求线程共享，多线程并发修改成员变量会出现数据覆盖、数据错乱问题。解决方式：Controller中尽量不定义成员变量；必须使用时，将变量定义为局部变量，或用ThreadLocal保证线程隔离，也可以将Controller改为多例模式（不推荐，损耗性能）。3、SpringAOP的实现原理？常用通知类型？AOP核心是动态代理，Spring默认优先JDK动态代理（接口代理），目标类无接口时使用CGLIB字节码代理。在不修改原有业务代码的前提下，对方法进行增强，实现日志、事务、权限、限流等通用功能解耦。常用通知类型：前置通知、后置通知、返回通知、异常通知、环绕通知，其中环绕通知功能最强，可手动控制方法执行、拦截、放