Java高频面试场景题

Java高频面试之Nacos如何进行配置同步客户端如何获取配置视频讲解了 Nacos 配置中心的配置同步逻辑及客户端配置获取流程。首次拉取配置应用服务启动时通过 HTTP 请求向 Nacos 服务端拉取对应配置获取后将配置缓存至本地内存、持久化到本地文件业务代码提取配置时优先读取本地缓存减少网络开销。配置变更感知客户端首次拉取配置后会持续向服务端发起长轮询请求服务端收到请求后挂起连接默认等待 30 秒期间若配置变更则立即返回最新配置若无变更则 30 秒后返回空响应客户端收到响应后会发起新的长轮询请求。配置更新生效客户端通过长轮询感知配置变更后会再次请求拉取最新配置更新本地内存与文件同时触发注册的监听器执行自定义逻辑如刷新 value 注解属性、重新初始化 bean让业务代码使用最新配置。这套机制兼顾了配置读取效率与变更实时性。分库分表导致的数据倾斜如何解决以下是分库分表数据倾斜问题的结构化总结一、数据倾斜定义分库分表后数据未均匀分布导致部分分片出现数据集中、热点或性能瓶颈。例如订单表按用户 ID 分片若某大 V 用户订单量远超其他用户其所在分片会因数据量过大导致查询和写入变慢。二、数据倾斜成因分片键选择不当分片键如用户 ID本身分布不均或未考虑业务场景如大 V 用户特性。分片算法缺陷简单哈希如取模无法应对数据分布不均易导致热点集中。业务特性影响时间范围分片如按日、月可能因促销活动如双十一导致某时段数据激增。三、解决方案优化分片键与算法选择更均匀的分片键结合业务场景优先选择分布更均衡的字段如订单时间 用户 ID 组合。使用一致性哈希或虚拟槽如 Redis 的虚拟槽算法通过虚拟节点实现数据更均匀分布并支持动态调整。手动调整热点分片将热点数据单独分配到独立分片避免与其他数据竞争资源。热点数据隔离缓存热点数据使用 Redis 等缓存中间件减少对数据库的直接访问压力。二次拆分热点数据对大 V 用户数据进一步按时间或业务维度拆分如按订单类型分散到多个分片。动态监控与调整实时监控分片负载通过数据库监控工具如 Prometheus Grafana实时观察各分片的 CPU、IO、QPS 等指标。自动迁移数据当发现某分片负载过高时自动迁移部分数据到其他分片平衡负载。四、核心思路总结解决数据倾斜的关键是分散热点、均匀分布通过分片键优化和算法升级减少数据集中。通过缓存和二次拆分隔离热点数据。通过动态监控和自动迁移实现资源平衡。以上方案可根据具体业务场景灵活组合使用核心在于提前预防和动态调整。5000万条数据如何统计流量最大有多少条数据视频讲解了字节面试题 “5000 万条数据下统计流量最大值” 的解题思路与性能优化方案。核心解题思路采用差分数组 扫描线方法。先和面试官确认统计单位以秒为例将每条带开始、结束时间的记录拆成两个事件点开始时间 1结束时间的下一秒 - 1将事件点按时间排序后从头扫描累加每秒变化值累加值的最大值即为流量峰值。5000 万数据优化第一步分页取数每次从数据库取 1 万条避免一次性查询压垮数据库第二步用多线程处理每批数据充分利用多核 CPU 性能。线程安全与坑点多线程环境下使用 ConcurrentSkipListMap 存储数据保证有序遍历且线程安全注意分页取数存在深度分页问题可结合游标分页优化。题干细节确认需灵活询问面试官若仅统计某时间段需给时间字段加索引。面试时可按 “先讲解题思路再讲性能优化” 的逻辑作答。3分钟带你降维打击HTTPS底层逻辑视频围绕 HTTPS 底层逻辑展开核心观点是 “混合加密”先用非对称加密确保安全再用对称加密提升效率兼顾安全性与性能。核心内容总结非对称加密的局限非对称加密如 RSA安全性高但计算量大、速度慢若全程使用会导致服务器资源耗尽、网页加载卡顿。混合加密的破局思路数字证书验证身份服务器通过 CA 颁发的数字证书 “亮证”浏览器验证证书有效性未篡改、权威机构颁发确认对方身份可信。非对称加密交换密钥服务器公开公钥客户端生成对称加密密钥如 AES用公钥加密后传输给服务器即使黑客截获数据也无法用公钥解密只有服务器的私钥能打开。对称加密高速传输双方拿到共享密钥后后续数据如密码、图片、视频用对称加密速度快、效率高传输保证用户体验流畅。底层智慧HTTPS 并非 “一根筋” 依赖单一加密方式而是通过 “数字证书自证清白 → 非对称加密安全交换密钥 → 对称加密高速传输” 的组合拳取长补短实现安全与性能的平衡。延伸思考视频最后提出问题若 CA 机构被黑客攻击HTTPS 是否仍安全这涉及证书信任链的核心风险 —— 若 CA 私钥泄露黑客可伪造证书但现代浏览器通过 “证书透明度”“撤销机制” 等措施降低风险同时用户需警惕异常提示如 “证书不受信任”。布隆过滤器你真的懂了吗视频讲解了布隆过滤器的底层逻辑、读写流程及特性助力程序员应对面试。核心结构类比将布隆过滤器类比为满是电灯开关的墙对应计算机里的位数组初始状态全为 0仅存状态不存内容极其节省空间视频称存一亿个状态仅占用少量内存。数据写入流程存入数据时调用多个哈希函数对数据计算得到多个位置将位数组对应位置设为 1即按亮对应开关。数据查询逻辑查询数据时用相同哈希函数计算位置若有任意位置为 0说明数据绝对不存在该结论 100% 准确。误判原因说明若查询的所有位置均为 1可能是其他数据的哈希计算凑巧点亮了这些位置即哈希碰撞导致误判无法百分百确认数据存在。删除限制说明标准布隆过滤器无法删除数据因为关闭对应位置会影响其他已存入的数据。视频最后提出问题若业务需频繁删除数据该如何改造或替换标准布隆过滤器。Mysql违背最左前缀原则一定会全表扫描吗 Skip Scan 了解一下MySQL 8.0 的索引跳跃扫描可打破联合索引最左前缀原则限制。老规则说明此前联合索引查询需遵循最左前缀原则若未匹配最左侧列会执行全表扫描。新优化逻辑MySQL 8.0 引入索引跳跃扫描Index Skip Scan当联合索引最左侧列基数较小时优化器会自动将查询拆分为多个匹配最左侧列不同取值的子查询再合并结果以此跳过最左侧列使用后续列的索引。适用前提仅当联合索引最左侧列基数小如仅含男女两个取值时触发若最左侧列是身份证号、手机号这类高基数唯一值拆分查询成本高于全表扫描仍会执行全表扫描。面试应答提示回答联合索引相关问题时可补充该优化特性体现对 MySQL 新版本的了解。掌握该特性可在 MySQL 相关面试中展现更全面的知识储备Java高频面试之kafka的吞吐量为什么要高很多Kafka 凭借多项核心设计实现远高于同类消息队列组件的吞吐量。磁盘顺序读写Kafka 将所有消息追加到文件末尾采用磁盘顺序写操作完全避免磁盘寻址带来的随机 IO 开销视频指出磁盘顺序写速度甚至快于内存随机写。零拷贝技术传统数据传输需经磁盘、内核缓冲区、用户缓冲区、socket 缓冲区到网卡存在多次态切换与数据拷贝Kafka 直接将数据从磁盘内核缓冲区传输到网卡跳过用户态减少上下文切换与数据复制次数。批量处理机制生产者攒够多条消息或达到指定时间再批量发送将多次小 IO 合并为一次大 IO减少网络请求次数消费者同样批量拉取消息进行处理。分区并行机制Kafka 的主题可拆分为多个分区分布在不同 broker 中生产者可并行从多分区读取数据该机制支持横向扩展能利用集群所有机器资源搭配副本机制在保证高可用的同时实现负载均衡。二进制消息格式Kafka 采用二进制消息格式数据更紧凑序列化与反序列化速度更快还能节省网络带宽与存储空间。以上多项设计共同作用推高了 Kafka 的整体吞吐量。万人群聊消息已读未读怎么设计视频讲解万人群聊消息已读未读功能的四种设计方案及各方案的优劣与适配场景。数据库直存方案通过建表记录消息 ID、用户 ID 和已读状态发消息时批量插入万条记录用户查看时更新状态但高并发场景下如每分钟 100 条消息会产生百万次数据库写入无法支撑。Redis Hash 方案以消息 ID 为大 Key、用户 ID 为 field 存储已读状态代码易实现但单条消息需存储万个 field多群多消息会占用大量 Redis 内存易引发溢出。普通 Bitmap 方案用位存储用户已读状态1 万用户仅占约 1.3KB 空间更新状态时间复杂度为 O (1)性能优异但依赖连续自增用户 ID若使用雪花算法生成的稀疏长整型 ID会因补齐零位占用大量内存。稀疏 ID 适配方案包含两种解决办法一是业务层为群内用户分配连续自增序号作为 offset避开稀疏 ID 问题二是使用 Roaring Bitmap其通过高低位分桶压缩稀疏数据Java 中可调用 Redisson 的 RPSet API 实现。你以为用Redis存点赞就能抗住百万并发视频讲解了百万并发点赞场景下的后端系统设计方案与面试考察要点。面试场景还原面试官问有四年经验的后端开发者百万并发点赞的设计方案开发者提出用 Redis 存点赞数并定时同步数据库被追问数据同步混乱问题后无法给出合理解决方案面试结束。考察核心说明该问题考察的是开发者对高并发场景下状态管理和最终一致性的设计能力而非单纯的 Redis 使用能力。第一层防御设计客户端将点赞 / 取消请求封装成消息写入 Kafka消息入队后立刻返回前端通过消息队列实现异步削峰避免冲击后端。第二层防御设计用 Redis 的 Hash 结构存储用户点赞状态用户查看时直接从 Redis 读取用布隆过滤器兜底内存不足的情况用 Redis 的 incr 维护实时点赞总数保障读请求性能。第三层防御设计消费端从 Kafka 拉取消息按视频 ID 分组批量更新数据库同一用户的操作以最后一条消息为准每条消息带全局唯一 ID消费前查 Redis 去重每天凌晨定时对比 Redis 与数据库的点赞数不一致则自动修复保证最终一致性。该方案体现了从缓存使用到高并发状态管理系统的工程思维。Java 中 ThreadLocal 的底层逻辑、内存泄露真相及相关面试核心问题。数据存储逻辑ThreadLocal 仅作为访问钥匙真实数据存储在线程对象的 ThreadLocalMap 中数据随线程生命周期存在线程存活则数据留存。弱引用设计目的弱引用并非引发内存泄露而是为避免 Key 无法回收。若 Key 为强引用即使外部 ThreadLocal 对象设为 null线程存活时 Map 内 Key 也无法删除会造成 100% 内存泄露弱引用下外部无引用时GC 会回收 Key 为 null且 JDK 在 get ()、set () 时会清理 Key 为 null 的脏 Entry。内存泄露原因若使用 ThreadLocal 后未调用 remove ()也未触发 get/set 方法(null, Value) 的脏数据会留存于线程池的线程中线程不销毁则 Value 持续占用内存。线程池风险线程池复用线程时若前一个请求未 remove () ThreadLocal 数据后续请求会读取到前一个请求的数据引发数据串号的业务事故后果比内存泄露更严重。FastThreadLocal 优势JDK 的 ThreadLocalMap 采用开放寻址法解决哈希冲突ThreadLocal 数量多时读写效率下降Netty 的 FastThreadLocal 用数组存储给每个变量分配固定索引get () 操作为 array [index]复杂度 O (1)无哈希计算与冲突检测效率更高。本次讲解还提及一份涵盖 80% 项目场景与八股文的大厂 P6 到 P7 学习路线图及 Java 高频面试题。