2025年高频javac面试题及答案

2025年高频javac面试题及答案Java中String、StringBuilder、StringBuffer的区别是什么？String是不可变类，底层使用final修饰的char数组存储（JDK9后改为byte数组），每次对String的修改操作都会提供新的String对象，性能较低。StringBuilder和StringBuffer继承自AbstractStringBuilder，内部使用可变的char/byte数组，支持高效的字符串拼接。StringBuilder是非线程安全的，适用于单线程环境；StringBuffer通过synchronized修饰方法保证线程安全，适用于多线程环境。三者性能对比：StringBuilder>StringBuffer>String（频繁拼接场景）。Java17有哪些重要特性？Java17作为LTS版本，核心特性包括：密封类（sealedclass）限制类的继承，增强类型安全；模式匹配（PatternMatchingforinstanceof）简化类型检查逻辑，如`if(objinstanceofStrings){...}`直接获取强转后变量；switch表达式扩展，支持模式匹配和更简洁的语法；VectorAPI（孵化阶段）支持SIMD操作提升数值计算性能；移除实验性的AOT和JIT编译器；增强伪随机数提供器（RandomGenerator）提供更灵活的随机数提供方式。谈谈Java的值传递和引用传递。Java中只有值传递。基本数据类型传递的是值的副本，修改副本不影响原变量；引用数据类型传递的是对象引用的副本，副本和原引用指向同一对象，因此修改对象内容会影响原对象，但重新赋值引用副本不会改变原引用。例如：```javavoidchange(intx){x=10;}//调用后原int变量不变voidchange(Useruser){user.setName("new");}//原User对象属性被修改voidchange(Useruser){user=newUser();}//原引用仍指向旧对象```HashMap在JDK1.8中的底层结构和1.7有何不同？JDK1.7的HashMap使用数组+链表结构，哈希冲突时通过头插法将新节点插入链表头部；JDK1.8改为数组+链表+红黑树结构，当链表长度≥8且数组长度≥64时，链表转换为红黑树（查询时间复杂度从O(n)降至O(logn)），当红黑树节点数≤6时退化为链表。此外，1.8的扩容机制优化为尾插法（避免多线程扩容时的循环链表问题），计算哈希值时简化高位运算（hash=key.hashCode()^(hash>>>16)），扩容时节点索引计算通过`(oldCap&hash)==0`判断是否需要移动，减少rehash次数。ConcurrentHashMap如何保证线程安全？JDK1.7和1.8的实现差异？JDK1.7使用分段锁（Segment），每个Segment继承ReentrantLock，默认16个Segment，支持16个线程并发写，锁粒度为Segment；JDK1.8摒弃分段锁，采用CAS+synchronized实现，锁粒度细化到数组的单个节点（Node）。具体操作：put时通过CAS尝试插入节点，失败则使用synchronized锁定该节点所在的链表/红黑树的头节点，避免锁住整个桶。读操作无需加锁（通过volatile修饰Node的val和next字段保证可见性）。1.8的优化减少了锁竞争，提升了高并发场景下的性能。线程的生命周期有哪些状态？如何转换？Java线程状态定义在Thread.State枚举中，共6种：NEW：线程创建但未调用start()RUNNABLE：包括操作系统的运行（running）和就绪（ready）状态BLOCKED：等待synchronized锁时进入WAITING：调用wait()、join()、LockSupport.park()无超时参数时进入TIMED_WAITING：调用sleep(time)、wait(time)、join(time)、parkNanos()等带超时参数的方法时进入TERMINATED：线程执行完毕或异常终止状态转换示例：NEW→start()→RUNNABLE；RUNNABLE→获取不到锁→BLOCKED；RUNNABLE→调用wait()→WAITING（其他线程调用notify()/notifyAll()唤醒）；RUNNABLE→调用sleep(1000)→TIMED_WAITING（超时后回到RUNNABLE）；所有状态最终可能转为TERMINATED。synchronized和ReentrantLock的区别？核心差异：锁实现：synchronized是JVM层面的关键字，依赖monitorenter/monitorexit字节码，自动释放锁；ReentrantLock是JDK层面的类（基于AQS），需手动调用unlock()释放。公平性：synchronized默认非公平锁；ReentrantLock可通过构造函数指定公平锁（FairSync）或非公平锁（NonfairSync）。条件变量：ReentrantLock支持多个Condition对象（如生产者-消费者模型中区分不同等待队列），synchronized只有一个wait/notify队列。可中断性：ReentrantLock的lockInterruptibly()方法支持线程在等待锁时被中断；synchronized无法中断，只能等待锁释放。性能：JDK1.6后synchronized优化（偏向锁、轻量级锁、锁消除等），性能与ReentrantLock接近，高竞争场景下ReentrantLock更灵活。JVM的内存区域如何划分？各区域的作用及OOM场景？JVM内存分为线程共享和线程私有区域：线程共享：堆（Heap）：存储对象实例和数组，是GC的主要区域。OOM场景：对象数量过多或大对象无法分配（如无限循环创建对象，-Xmx设置过小）。方法区（MethodArea）：存储类信息、常量、静态变量（JDK7前为永久代，JDK8后改为元空间Metaspace，使用本地内存）。OOM场景（元空间）：动态提供大量类（如CGLIB代理、反射），-XX:MaxMetaspaceSize设置过小。运行时常量池（RuntimeConstantPool）：方法区的一部分，存储编译期提供的常量和符号引用（JDK7后字符串常量池移至堆）。OOM场景（JDK7前）：大量字符串intern()操作导致永久代溢出。线程私有：程序计数器（PCRegister）：记录当前线程执行的字节码行号，无OOM。虚拟机栈（VMStack）：存储栈帧（局部变量表、操作数栈、动态链接、方法出口）。OOM场景：线程请求的栈深度超过最大限制（如递归无终止条件，-Xss设置过小），抛出StackOverflowError；若允许动态扩展（多数JVM不支持），扩展失败时抛出OOM。本地方法栈（NativeMethodStack）：为本地方法服务，HotSpot将其与虚拟机栈合并，OOM场景同虚拟机栈。Spring的IOC容器如何解决循环依赖？Spring通过三级缓存解决单例Bean的循环依赖：一级缓存（singletonObjects）：存储已初始化完成的单例Bean。二级缓存（earlySingletonObjects）：存储已实例化但未初始化完成的早期Bean（用于解决AOP代理的循环依赖）。三级缓存（singletonFactories）：存储ObjectFactory工厂，用于提供早期Bean的引用（支持通过后置处理器提供代理对象）。流程示例：A依赖B，B依赖A。1.创建A实例（构造器注入完成），将A的ObjectFactory（lambda表达式：()->getEarlyBeanReference(beanName,mbd,bean)）存入三级缓存。2.A需要注入B，触发B的创建流程，B实例化后存入三级缓存。3.B需要注入A，从三级缓存获取A的ObjectFactory，提供早期A的引用（可能是代理对象），存入二级缓存，并移除三级缓存中的A工厂。4.B完成属性注入和初始化，存入一级缓存，移除二级缓存中的B。5.A获取到二级缓存中的B引用，完成属性注入和初始化，存入一级缓存，移除二级缓存中的A。注意：构造器注入的循环依赖无法解决（实例化阶段就需要依赖对象，此时三级缓存尚未提供），原型（prototype）Bean的循环依赖也无法解决（无缓存机制）。如何优化MySQL的慢查询？优化步骤：1.开启慢查询日志（slow_query_log），记录执行时间超过long_query_time（默认10秒）或无索引的查询（log_queries_not_using_indexes）。2.分析SQL执行计划（EXPLAIN），关注type（最好为const，最差为ALL）、key（实际使用的索引）、rows（扫描的行数）、Extra（是否Usingfilesort/Usingtemporary）。3.索引优化：为WHERE、JOIN、ORDERBY、GROUPBY中的列添加索引，避免在过滤性差的列（如性别）上建索引。遵循最左匹配原则（联合索引按顺序使用），避免索引失效（如对索引列使用函数、类型转换、!=、ISNULL等）。覆盖索引（索引包含查询所需的所有列）避免回表，如SELECTid,nameFROMuserWHEREage=20，若索引为(age,name,id)，则可直接从索引获取数据。4.SQL改写：避免SELECT，只查询需要的列。拆分复杂的多表JOIN（超过3张表），减少数据量。用IN替代OR（IN可利用索引，OR可能全表扫描）。批量操作替代循环插入（如INSERTINTOuserVALUES(1),(2),(3)）。5.数据库结构优化：垂直拆分（按列拆分）：将大字段（如TEXT）单独存表，减少主表数据量。水平拆分（按行拆分）：通过分库分表（如按ID取模）分散数据，降低单表容量。6.硬件优化：增加内存（减少磁盘IO）、使用SSD、调整MySQL配置（如innodb_buffer_pool_size设置为内存的50%-70%）。分布式事务的常见解决方案有哪些？各自适用场景？1.两阶段提交（2PC）：流程：协调者（Coordinator）发送准备（Prepare）指令，所有参与者（Participant）准备事务并反馈；若全部准备成功，协调者发送提交（Commit）指令，否则回滚。优点：强一致性。缺点：同步阻塞（参与者在准备阶段锁定资源）、单点故障（协调者宕机导致事务卡住）、网络问题可能导致数据不一致（如部分参与者未收到提交指令）。适用场景：数据库支持（如XA协议，MySQL的InnoDB支持XA事务）、低并发的关键交易场景（如银行转账）。2.补偿事务（TCC）：流程：Try（尝试执行业务，预留资源）→Confirm（确认提交，使用预留资源）→Cancel（取消，释放预留资源）。优点：无长时间资源锁定，支持跨服务的事务。缺点：开发成本高（需实现三个阶段的接口），Confirm/Cancel需幂等（防止重复调用）。适用场景：微服务架构中跨服务的事务（如电商的下单-扣库存-减积分）。3.最大努力通知：流程：主业务完成后，通过MQ异步通知从业务执行，若失败则重试（设置最大重试次数），最终达到一致。优点：实现简单，无锁资源。缺点：弱一致性（有延迟）。适用场景：对一致性要求不高的场景（如短信通知、邮件提醒）。4.事务消息（基于可靠消息）：流程：发送方先发送半消息（MQ不投递），执行本地事务，成功则确认消息（MQ投递），失败则回滚消息；接收方消费消息并执行本地事务，失败则重试。优点：异步解耦，最终一致性。缺点：依赖MQ的可靠性（如RocketMQ支持事务消息）。适用场景：需要异步通信的分布式系统（如订单系统通知库存系统）。如何解决Redis的缓存雪崩、穿透、击穿问题？缓存雪崩：大量缓存同一时间过期，请求直接打到数据库。解决方案：设置随机过期时间（如基础时间+随机数），避免集中失效；使用多级缓存（本地缓存+Redis）；数据库层做限流降级（如Hystrix）。缓存穿透：查询不存在的数据（如id=-1），缓存无命中，数据库也无记录，导致每次请求都查数据库。解决方案：缓存空对象（设置短过期时间），避免重复查询；使用布隆过滤器（BloomFilter）预处理，过滤不可能存在的key；接口层做参数校验（如id必须>0）。缓存击穿：热点key过期，大量请求同时访问该key，直接打到数据库。解决方案：热点key设置永不过期（异步更新）；使用互斥锁（如Redis的setnx），仅允许一个线程更新缓存，其他线程等待；本地缓存缓存热点数据（如GuavaCache）。JDK动态代理和CGLIB的区别？实现方式：JDK动态代理基于接口，通过Proxy类和InvocationHandler提供代理对象（只能代理接口方法）；CGLIB基于ASM字节码增强，通过继承目标类提供子类（可代理非final类的非final方法）。性能：JDK1.8后动态代理性能提升，短生命周期对象JDK更优；CGLIB因需要提供子类，初始化时间较长，但对多次调用的方法性能更优。适用场景：目标类有接口时用JDK动态代理（符合面向