你建的联合索引，到底能用上哪一列？
面试官通过三道 MySQL 联合索引题目，考察 3 年 Java 开发的索引理解深度。
面试提问环节：面试官针对 (user_id,age,name) 的用户表，以 (age,name) 联合索引为基础，先后提出三个问题：一是 WHERE name=' 张三 'AND age=20 时索引是否生效；二是 WHERE age>18 AND name="张三" 时索引是否全生效；三是调换 WHERE 条件顺序为 name=' 张三 'AND age>18 时，索引生效情况是否变化。候选人因误解最左前缀原则被问住。
核心本质拆解：
索引结构本质：MySQL 的 InnoDB 引擎索引为 B + 树结构，所有数据存于叶子节点且形成有序链表，可减少磁盘 I/O、适配范围查询，这是最左前缀原则的底层逻辑。
匹配规则本质：联合索引匹配基于索引定义的列顺序，而非 SQL 条件书写顺序，MySQL 优化器会自动重排符合最左前缀的条件顺序；范围查询后的列无法用于索引快速定位，仅能通过索引下推在内存过滤。
实战设计要点：联合索引需将区分度最高的列放最左；避免重复索引；尽量设计覆盖索引，减少回表查询以提升效率。
面试回答需结合索引底层结构、匹配规则及实战设计，体现专业深度。
百万玩家"同服内卷"，实时榜单如何计算？
视频讲解了百万玩家同服实时排行榜的高并发优化方案。
写风暴应对：采用本地微批处理，在业务服务 JVM 内存中用 ConcurrentHashMap 合并 1 秒内的增量积分，通过定时任务或守护线程每隔 1-2 秒批量刷入 Redis，将 10 万次写请求压缩为几千次，避免 Redis 单线程 CPU 占满。
读风暴应对：针对 99% 用户关注的前 100 名排名，将数据缓存至 JVM 的 Local Cache，查前 100 名的请求直接从本地内存返回，无需跨网络访问 Redis，避免带宽被撑爆。
大 Key 问题解决：按分数段拆分 ZSET，将满分 1 万分的榜单拆分为多个小 ZSET，如 9000-10000 分、8000-9000 分等桶，打散百万级数据；计算总排名时，叠加当前分数段之前所有桶的总人数与当前桶内排名即可。
高并发调优需结合多技术组合适配真实业务场景。
为什么阿里明令禁止的JDK线程池？
阿里开发手册明令禁止使用 JDK 自带线程池，视频以银行模型拆解其底层逻辑。
固定线程池问题：JDK 固定容量线程池默认将等候队列设为无限大，若遭遇千万级请求，未被处理的请求会挤满等候队列，每个任务占用内存资源，最终导致服务器内存耗尽触发 OOM。
缓存型线程池问题：JDK 缓存型线程池会根据请求数量无限制创建线程，大促等高并发场景下，若出现几十万请求，会瞬间创建几十万个线程，直接导致系统崩溃。
核心思想总结：系统资源分配必须设边界，开发者需手动控制线程池核心参数，包括队列容量、最大工作线程数等，避免依赖系统默认设置。
开发需对内存保有敬畏之心，需自主掌控线程池核心指标
视频讲解了 Kafka 消息积压扩容反变慢的问题及三层解决防御体系。
问题触发逻辑：订单量暴涨致 50 万条消息积压，延迟 1 小时；将 Kafka 分区从 10 个扩到 20 个、消费者加 10 个后，积压更严重，监控显示消费者频繁 rebalance，消费速度下降。
问题根源解析：消费者处理慢引发 GC 停顿超 5 秒，超过 Kafka 默认 10 秒的 session.timeout.ms 阈值，触发 rebalance；rebalance 期间所有消费暂停，加剧消息积压。
第一层防御：先诊断再扩容，查看 GC 频率与停顿时间，若 GC 超 3 秒先优化 GC；排查消息处理耗时原因，针对性解决；若频繁 rebalance，调大相关超时参数留足处理时间。
第二层防御：消费端优化，将业务逻辑丢给工作线程池，消费线程仅负责拉取消息与提交 offset；一次拉取 500 条消息批量写入数据库；用 MAT 分析堆 dump 检查内存泄露。
第三层防御：Kafka 参数调优，将 max.poll.records 从 500 降至 200，避免单次处理超时；session.timeout.ms 从 10 秒调至 30 秒，给 GC 留缓冲时间；max.poll.interval.ms 从 5 分钟调至 10 分钟，匹配业务耗时。
该问题考察开发者从单纯扩容到系统性诊断的工程思维。
消息中间件kafka如何避免消息丢失
大树讲解了 Kafka 避免消息丢失的三个核心环节配置修改方法。
生产者端配置：将默认 acks=1 改为 all 或 - 1，需所有副本同步完成才返回确认；开启重试机制，设置 retries 为 3-5 次，同时合理设置重试间隔，避免网络波动或 Broker 卡顿导致消息丢失。
Broker 端配置：将默认单副本改为副本数≥2，避免单副本服务器宕机丢失消息；设置 ISR 最小副本数≥2，需至少两个副本同步成功才算消息写入成功，同步副本数不足时 Broker 直接拒绝写入。
消费者端配置：将 enable.auto.commit 改为 false，关闭自动提交偏移量，改为在业务逻辑执行完成、消息处理成功后，手动调用 commit 方法提交偏移量，避免消费者未处理完消息就标记已消费导致丢失。
修改以上三类配置可杜绝 90% 以上 Kafka 消息丢失问题。
kafka如何保证消息不丢失？
视频讲解了从生产端、Broker 端、消费端及业务层面保障 Kafka 消息不丢失的具体方案。
生产端配置：设置 acks 为 all 或 - 1，需 ISR 列表所有副本确认消息接收才算发送成功；设置 retries 参数，避免网络抖动等临时故障导致发送失败，确保消息成功发送至 Broker。
Broker 端配置：采用副本机制，建议副本因子至少为 3，保证单 Broker 宕机时其他副本可提供服务；设置 min.insync.replicas 为 2，配合 acks 参数，同时避免 unclean 选举，防止非 ISR 副本成为 Leader 导致数据丢失，保障消息持久化。
消费端配置：关闭自动提交偏移量，改为手动提交，遵循先处理业务逻辑再提交 offset 的原则，处理失败时不提交 offset；同时保证消费端幂等性，避免重复消费引发业务问题。
业务兜底方案：发送消息时记录日志或落库，若发现消息丢失，可通过离线任务对比修复，作为最后防线降低丢失风险。
Kafka 需多端协同配置并结合业务补偿，同时需平衡可靠性与性能，根据业务场景选择参数。
Java 面试中 Integer 与 int 的区别及封装类设计逻辑的核心考点与应答思路。
考察核心方向：视频明确该题针对 1-3 年经验求职者，考察三点：一是对基本类型与封装类的基础认知；二是对 Java 面向对象设计思想的理解；三是结合项目场景的实操能力。
二者核心区别：int 是基本数据类型，可直接赋值，默认值为 0，存储在栈空间；Integer 是 int 的封装类，需用 new 关键字创建对象，默认值为 null，存储在堆内存，封装了操作数据的方法和属性；二者混合使用时 Java 会自动拆箱、装箱。
封装类设计原因：Java 是面向对象语言，集合（如 List、HashMap）仅能存储对象类型；封装类可隐藏实现细节，保证数据传递安全性，调用方法操作数据更便捷。
视频还展示了面试高手的标准化应答示例。
业务线程池该共享还是独享？
视频详解 Java 业务线程池共享与独享的选型逻辑、落地方案及面试标准作答内容。
核心优劣对比：共享线程池可提升资源利用率、简化维护，但存在无隔离易致全系统崩溃、无法单独调优监控的致命风险；独享线程池可实现强隔离、精准调优监控，但线程总数多、管理成本较高。
落地决策维度：CPU 密集型、耗时不稳定的 IO 型任务，核心业务，流量洪峰类业务必须用独享线程池；耗时短且稳定的 IO 型任务，非核心业务，常规零散任务可采用共享线程池。
大厂实战方案：电商系统中，订单、支付、第三方物流业务用独享线程池，短信、日志等非核心业务用共享线程池，采用核心 + 高风险独享、非核心共享的混合模式。
面试标准作答：采用 "隔离 + 复用" 混合模式，明确决策依据，结合项目实践说明线程池配置，同时提及线程池命名、监控、动态调参等细节。
线程池选型的本质是系统稳定与资源效率的平衡。