高频java后台开发面试题及答案

高频java后台开发面试题及答案Java中==和equals()的区别是什么？==对于基本数据类型比较的是值是否相等，对于引用类型比较的是内存地址是否相同。equals()是Object类的方法，默认实现等同于==，但通常会被重写（如String、Integer等类），用于比较对象的内容是否相等。例如String的equals()会逐个字符比较，而Integer的equals()会比较int值。需注意重写equals()时必须同时重写hashCode()，以保证哈希集合（如HashMap）的正确性，因为哈希集合通过hashCode()快速定位桶位置，再通过equals()比较元素是否相等。ArrayList和LinkedList的底层结构及适用场景？ArrayList底层是动态数组，默认初始容量10，当容量不足时通过Arrays.copyOf()扩容（约1.5倍）。优点是随机访问时间复杂度O(1)，缺点是插入/删除（非末尾）需要移动元素，时间复杂度O(n)。LinkedList底层是双向链表（JDK1.6前为循环链表，1.7后取消循环），每个节点包含前驱、后继指针和数据。优点是插入/删除（已知位置）时间复杂度O(1)（实际需先遍历找到位置，所以平均O(n)），缺点是随机访问需遍历，时间复杂度O(n)。因此，频繁随机访问选ArrayList，频繁插入删除（尤其中间）选LinkedList，但实际开发中ArrayList更常用，因数组的内存连续性带来的缓存友好性通常比链表的插入优势更明显。HashMap的底层实现及JDK7与JDK8的差异？JDK7中HashMap底层是数组+链表，数组作为哈希表，每个数组元素是链表头节点。通过key的hashCode()计算哈希值，再通过(n-1)&hash（n为数组长度，需是2的幂）确定桶位置。链表节点是Entry类型，包含hash、key、value、next指针。当链表长度过长（默认>8且数组长度≥64），JDK8会将链表转换为红黑树（TreeNode），以将查询时间从O(n)降至O(logn)；当红黑树节点数≤6时，退化为链表。JDK8的主要改进：①数组+链表→数组+链表+红黑树；②哈希计算优化，hash()方法改为(h=key.hashCode())^(h>>>16)，减少高位信息丢失导致的哈希冲突；③插入方式从头插法（JDK7）改为尾插法（JDK8），避免多线程扩容时的链表成环问题（但HashMap本身非线程安全，多线程仍需用ConcurrentHashMap）；④resize()时重新计算索引的方式优化，原索引要么不变，要么+原数组长度，无需重新计算hash。ConcurrentHashMap如何保证线程安全？JDK7中使用分段锁（Segment），继承ReentrantLock，默认16个Segment，每个Segment独立加锁，支持16个线程并发写。每个Segment包含一个HashEntry数组，链表结构。put操作时先定位Segment，再对该Segment加锁，保证同一Segment内的操作互斥，不同Segment可并行。JDK8摒弃分段锁，采用CAS+synchronized实现。数组节点为Node类型，当插入元素时，若桶为空（null），通过CAS尝试直接插入；若桶不为空且头节点不为红黑树根节点（即链表状态），使用synchronized锁住头节点，遍历链表插入（或转红黑树）；若为红黑树，锁住根节点进行操作。这种方式降低了锁粒度（从Segment到桶的头节点），并发度更高。此外，size()计算时JDK7通过累加各Segment的count（可能需重试），JDK8通过baseCount（基础计数）+counterCells（冲突时的增量数组），减少CAS竞争。synchronized和Lock的区别？①锁的获取方式：synchronized是关键字，隐式加锁/释放（JVM自动处理，异常时自动释放）；Lock是接口（如ReentrantLock），需显式调用lock()/unlock()（通常在finally中释放）。②锁的特性：synchronized是非公平、不可中断、不可尝试获取锁；Lock支持公平锁/非公平锁（默认非公平）、可中断（lockInterruptibly()）、可尝试获取（tryLock()）。③条件变量：synchronized配合wait()/notify()/notifyAll()（属于Object类），功能单一；Lock配合Condition（如newCondition()），可实现多个等待队列（如读写锁的读线程和写线程分开等待）。④性能：JDK6后synchronized通过锁升级（偏向锁→轻量级锁→重量级锁）优化，性能与Lock接近，但高竞争场景下Lock（如ReentrantLock）的可预测性更好。Java内存模型（JMM）如何解决可见性和有序性问题？JMM定义了主内存与工作内存的抽象关系，规定所有变量存储在主内存，线程有自己的工作内存（缓存、寄存器等），线程对变量的操作需先拷贝到工作内存，不能直接操作主内存。可见性问题通过volatile、synchronized、Lock保证：volatile变量的写操作会立即刷新到主内存，读操作会失效本地缓存，强制从主内存读取；synchronized的解锁操作会刷新主内存，加锁操作会使工作内存失效，保证可见性。有序性问题通过happens-before原则和volatile的内存屏障解决。happens-before规则包括程序顺序规则（单线程内操作有序）、管程锁定规则（解锁前的操作对加锁后可见）、volatile变量规则（写volatile先于读）、传递性等。volatile变量在写操作前插入StoreStore屏障（禁止上面的普通写和volatile写重排序），写操作后插入StoreLoad屏障（禁止volatile写和下面的volatile读/写重排序）；读操作前插入LoadLoad屏障（禁止下面的普通读和volatile读重排序），读操作后插入LoadStore屏障（禁止volatile读和下面的普通写重排序），从而禁止特定类型的指令重排。线程池的核心参数及拒绝策略？线程池通过ThreadPoolExecutor创建，核心参数：①corePoolSize：核心线程数，即使空闲也不会被销毁（除非设置allowCoreThreadTimeOut为true）。②maximumPoolSize：最大线程数，当任务队列满时，可创建的最大线程数（不能小于corePoolSize）。③keepAliveTime：非核心线程的空闲存活时间（allowCoreThreadTimeOut为true时，核心线程也适用）。④unit：时间单位。⑤workQueue：任务队列，常用有ArrayBlockingQueue（有界数组）、LinkedBlockingQueue（无界链表，默认大小Integer.MAX_VALUE，可能导致OOM）、SynchronousQueue（无存储，直接提交给线程）、PriorityBlockingQueue（优先队列）。⑥threadFactory：线程工厂，用于创建线程（建议自定义，设置有意义的线程名，方便排查问题）。⑦handler：拒绝策略，当任务队列满且线程数达最大值时触发。JDK提供4种策略：AbortPolicy（默认，抛出RejectedExecutionException）、CallerRunsPolicy（调用者线程执行任务）、DiscardPolicy（直接丢弃任务）、DiscardOldestPolicy（丢弃队列中最老的任务，再尝试提交）。实际开发中建议根据业务场景选择有界队列（避免OOM）和自定义拒绝策略（如记录日志或触发报警）。Spring的IOC和AOP的实现原理？IOC（控制反转）的核心是容器管理对象的创建和依赖注入，通过XML配置、注解（@Component、@Autowired）或Java配置（@Configuration、@Bean）定义Bean。实现原理包括：①BeanDefinition的加载：通过BeanDefinitionReader读取配置（如ClassPathXmlApplicationContext读取XML，AnnotationConfigApplicationContext读取注解），解析为BeanDefinition（存储Bean的类名、作用域、依赖等信息）。②BeanFactoryPostProcessor（如PropertyPlaceholderConfigurer）可修改BeanDefinition（如替换占位符）。③Bean的实例化：通过反射（无参构造或有参构造，需处理循环依赖）或工厂方法（静态工厂、实例工厂）创建对象。④依赖注入：通过字段注入（@Autowired）、构造器注入（@ConstructorBinding）或setter注入，解析依赖的Bean（可能涉及自动装配byName/byType）。⑤BeanPostProcessor（如ApplicationContextAwareProcessor）在Bean初始化前后进行处理（如设置Aware接口属性、AOP代理）。AOP（面向切面编程）通过动态代理实现，解决横切关注点（如日志、事务、权限）的重复代码问题。Spring支持JDK动态代理（针对接口，通过InvocationHandler）和CGLIB代理（针对类，通过MethodInterceptor）。当Bean实现了接口时，默认用JDK代理；否则用CGLIB（可通过配置强制使用CGLIB）。AOP的核心概念包括：①切面（Aspect）：包含切点（Pointcut，定义匹配的连接点）和通知（Advice，如@Before、@After、@Around）。②连接点（Joinpoint）：程序执行的某个点（如方法调用、异常抛出）。③织入（Weaving）：将切面逻辑插入目标对象的过程，Spring采用运行时织入（通过代理对象）。实现流程：①解析@Aspect注解的Bean，提取切点和通知。②通过BeanPostProcessor（AnnotationAwareAspectJAutoProxyCreator）在Bean初始化后，判断是否需要代理（匹配切点）。③创建代理对象（JDK或CGLIB），代理对象持有目标对象和切面逻辑。④调用代理方法时，执行通知链（按@Order顺序），再调用目标方法。Spring如何解决循环依赖？循环依赖指A依赖B，B依赖A。Spring仅能解决单例Bean的字段注入或setter注入的循环依赖，无法解决构造器注入（因构造器调用时需依赖的Bean尚未实例化）。核心机制是三级缓存：①singletonObjects（一级缓存）：存储已初始化完成的单例Bean。②earlySingletonObjects（二级缓存）：存储已实例化但未初始化完成的早期Bean（用于解决AOP代理的循环依赖）。③singletonFactories（三级缓存）：存储ObjectFactory（工厂对象，用于提供早期Bean，可能包含AOP代理逻辑）。流程：当创建A时，首先标记A为“正在创建”，将A的ObjectFactory（()->getEarlyBeanReference(beanName,mbd,bean)）放入三级缓存。然后处理A的依赖B，触发B的创建。B创建时依赖A，此时A未完成初始化，从三级缓存获取A的ObjectFactory，提供早期Bean（可能是代理对象）放入二级缓存，并移除三级缓存的工厂。B完成初始化后放入一级缓存，回到A的创建流程，将B注入A，A初始化完成后放入一级缓存，并移除二级缓存的早期Bean。若存在AOP，getEarlyBeanReference()会提前提供代理对象，保证依赖的是代理后的实例而非原始对象，避免循环依赖中引用原始对象导致的不一致问题。MySQL的索引类型及优化策略？索引类型：①B+树索引（最常用）：InnoDB和MyISAM的默认索引，叶子节点存储完整数据（聚簇索引）或主键（非聚簇索引）。聚簇索引（主键索引）的叶子节点是数据行，一个表只能有一个；非聚簇索引（二级索引）的叶子节点是主键值，需回表查询（通过主键查聚簇索引）。②哈希索引：Memory引擎支持，通过哈希值快速定位，不支持范围查询和排序。③全文索引：用于文本搜索（如MyISAM的FULLTEXT，InnoDB5.6+支持）。④空间索引：用于几何数据（如POINT、POLYGON）。优化策略：①避免全表扫描，通过EXPLAIN分析查询计划，检查type是否为ref/eq_ref（好）或ALL（差）。②遵循最左匹配原则（联合索引a,b,c，可匹配a、a,b、a,b,c，但无法匹配b、b,c）。③索引列避免使用函数或表达式（如WHEREYEAR(create_time)=2023，会导致索引失效）。④覆盖索引（查询的列都在索引中）避免回表，如SELECTid,nameFROMuserWHEREname='张三'，若name是索引且包含id（联合索引name,id），则直接从索引获取数据。⑤索引不是越多越好，插入/更新会维护索引，增加开销。⑥长字符串使用前缀索引（如INDEX(email(10))），减少索引大小。⑦主键尽量用自增整数（B+树顺序插入，减少分裂），避免随机UUID（导致索引页分裂，降低性能）。Redis的持久化机制及选择建议？Redis支持RDB（快照）和AOF（日志追加）两种持久化方式，可同时开启。RDB：通过bgsave命令（异步）或配置自动触发（如save9001：900秒内至少1次写操作），将当前内存数据快照写入磁盘（默认dump.rdb）。优点是文件紧凑（二进制格式），恢复速度快；缺点是可能丢失最后一次快照后的所有数据（取决于触发频率）。AOF：记录所有写操作命令（appendonly.aof），通过appendfsync配置刷盘策略（always：每次写都刷盘，最安全但最慢；everysec：每秒刷盘，默认，兼顾性能和安全；no：由OS决定，最快但可能丢失较多数据）。AOF文件会不断增大，通过bgrewriteaof命令重写（合并重复命令，如多次set同一key合并为最后一次）。优点是数据完整性高（everysec策略最多丢失1秒数据）；缺点是文件较大，恢复速度比RDB慢。选择建议：若允许少量数据丢失（如缓存场景），可仅用RDB；若需高数据完整性（如会话存储），建议同时开启RDB和AOF（AOF为主，RDB作为备份）。生产环境中通常RDB用于灾难恢复（文件小，易传输），AOF用于日常数据恢复。分布式事务的解决方案？①两阶段提交（2PC）：通过协调者（Coordinator）和参与者（Participant）实现。阶段1（准备）：协调者向所有参与者发送准备请求，参与者执行事务但不提交，返回成功/失败。阶段2（提交/回滚）：若所有参与者准备成功，协调者发送提交命令；否则发送回滚命令。缺点是同步阻塞（参与者等待协调者）、单点故障（协调者宕机导致事务卡住）、数据不一致（协调者发送提交后部分参与者未收到，导致部分提交）。②三阶段提交（3PC）：增加CanCommit阶段（询问参与者是否可执行事务，避免资源长时间锁定）和PreCommit阶段（准备事务但不提交），最后DoCommit阶段提交。但仍未完全解决阻塞问题，实际应用较少。③TCC（Try-Confirm-Cancel）：补偿型事务。Try阶段：预留资源（如冻结账户余额）；Confirm阶段：提交资源（扣除冻结余额）；Cancel阶段：释放预留资源（解冻余额）。需保证Confirm/Cancel的幂等性（多次调用结果一致）。优点是异步非阻塞，适合高并发场景；缺点是开发成本高（需实现三个方法）。④事务补偿（Saga）：将长事务拆分为多个短事务，每个事务提交后，若后续事务失败，通过补偿事务回滚之前的操作（如订单服务→库存服务→支付服务，支付失败则调用库存的补偿方法增加库存，订单的补偿方法取消订单）。需保证补偿操作的幂等性和最终一致性。⑤本地消息表（阿里的Seata也支持此模式）：业务操作和消息记录在同一个本地事务中（如订单表和消息表插入操作在一个事务），消息服务轮询消息表，发送消息给其他服务，其他服务处理后更新消息状态。通过重试机制保证消息最终被处理。优点是基于关系型数据库的ACID，实现简单；缺点是消息表需独立维护，可能存在消息堆积。实际中，根据业务场景选择：强一致性需求（如金融转账）可选2PC（依赖可靠的协调者，如Seata的AT模式）；高并发场景选TCC；最终一致性选本地消息表或Saga。如何设计一个高并发的接口？①限流：通过Nginx（limit_req/limit_conn）、Sentinel或Guava的RateLimiter限制请求频率（如QPS限制为1000）。②缓存：热点数据缓存到Redis（如用户信息），减少数据库压力。使用本地缓存（Caffeine）+分布式缓存（Redis）的多级缓存，降低缓存击穿风险。③异步处理：非核心逻辑（如日志记录、消息通知）通过MQ（RabbitMQ、Kafka）异步处理，接口仅返回任务ID，用户通过轮询或回调获取结果。④分库分表：单库QPS过高时，按用户ID取模分库（如user_0到user_9），按时间分表（如order_202301），减少单表数据量。⑤数据库优化：使用连接池（HikariCP），批量插入（INSERTINTO...VALUES(),(),()），读写分离（主库写，从库读，通过中间件如MyCat路由）。⑥接口幂等性：通过Token机制（前端请求前获取Token，请求时携带，服务端校验后删除）、数据库唯