- 博客(17)
- 收藏
- 关注
RSS订阅原创 遇到线上问题的解决方案
先定位溢出类型 → 抓快照看对象分布 → 查引用链找泄漏点 → 结合业务修复”。关键在于理解 JVM 内存模型（堆、元空间、直接内存等）的特性，以及常见的内存泄漏场景（静态引用、缓存失控、资源未释放）。线上问题往往不是单一原因，需结合日志、监控和代码多维度验证。
2025-10-16 12:56:54
1655
原创 MySQL分库分表
不需要分：单表数据量 < 500 万，QPS<1000，业务增长平缓（如内部管理系统），优先优化 SQL（加索引、SQL 改写）和数据库配置（分表会增加复杂度，过早优化反而麻烦）。优先垂直拆分：表字段过多（20+）、业务模块清晰（如订单和用户完全独立），先垂直分表 / 分库，复杂度低，见效快。必须水平拆分：单表数据量 > 1 亿，QPS>5000（如电商订单、秒杀），需水平分表 / 分库，结合中间件降低复杂度。
2025-10-16 12:48:42
311
原创 Kafka队列面试题
结论：Kafka 只有消费者主动拉取（Pull）一种模式，无默认推送模式。核心逻辑：消费者通过poll()方法基于 Offset 批量拉取消息，Broker 仅被动响应，这种设计是 Kafka 实现高吞吐、高并发的关键。记忆点：Kafka 是 “消费者说了算”，想要消息自己来拿，Broker 不做 “主动送货上门” 的事。
2025-10-16 12:44:39
610
原创 面试记录(一)
4. 场景设计: 如何设计用redis存储类似MySQL的索引?如何根据一个索引的uuid去查询它关联的所有主键id的行记录?如何在进行select * 操作去查询完联合索引后,如何利用redis进行回表查询其他字段数据?5. 算法设计: 给定一个字符串,我们需要找到它长度最长的一个严格递增子序列,你该如何设计?3. 场景设计: 如何用redis实现一个简化版的关系型数据库(类似MySQL),不考虑事务的情况下？1. 了解redis的 主从切换吗?2. 了解redis的主从复制吗?8. 工作流了解吗?
2025-09-21 01:31:22
141
原创 Redis分布式锁相关问题
互斥性破坏（超时、主从同步）、操作原子性问题、功能缺陷（不可重入、非公平）。用原子命令获取锁，确保锁的原子性设置；释放锁时用 Lua 脚本原子化校验并删除（判断 value 是否为自己的标识）；引入 “锁续期” 机制（如 Watch Dog 自动延长过期时间）解决超时问题；复杂场景可考虑 Redisson 等成熟框架（内置解决重入、续期、主从一致性等问题）。
2025-09-17 19:03:29
473
原创 力扣hot100 图论板块题解
遍历网格找陆地，找到后用 DFS/BFS 淹没所有相连陆地，计数加 1，最终计数即为岛屿数。无需额外空间标记已访问（直接修改原网格为'0'即可，题目未要求保留原网格）；严格判断边界（避免数组越界）；只遍历水平 / 竖直方向（斜向不算相邻）。两种方法的时间复杂度都是O(m*n)（每个单元格最多访问一次），空间复杂度取决于递归深度（DFS）或队列大小（BFS），最坏情况为O(m*n)（全是陆地时）。Queue是处理顺序元素的核心接口，通过offer()入队、poll()出队、peek()
2025-09-16 02:58:34
742
原创 分布式事务Seata中间件相关面试题
2PC 是分布式系统中保证事务一致性的经典协议，核心分两步：①准备阶段：协调者向所有参与者发送‘准备提交’请求，参与者执行本地事务但不提交，仅返回‘成功就绪’或‘失败’的响应；②提交阶段：若所有参与者都就绪，协调者发‘最终提交’命令，参与者执行提交；只要有一个失败，协调者发‘回滚’命令，所有参与者撤销操作。本质是用‘强协调’确保分布式环境下，事务要么全成、要么全败。AT 模式（Automatic Transaction Mode）是 Seata 基于“本地事务表 + 全局锁”
2025-09-10 02:49:36
629
原创 力扣hot100 普通数组板块算法题题解
解决这道题的核心是“先排序，再合并”—— 排序解决了区间顺序混乱的问题（如示例 3），后续的合并只需线性遍历即可完成，时间复杂度主要由排序决定（O (nlogn)，n 为区间数量），效率较高。复杂度类型结果关键原因时间复杂度O(n log n)排序操作主导，遍历为线性时间空间复杂度O(n)存储结果数组 + 排序的临时空间这是「合并区间」问题的最优复杂度，因为排序操作本身无法突破 O (n log n) 的下限，而后续的线性遍历已经是最优效率。JDK 7 及以后：使用TimSort 算法。
2025-09-10 01:37:39
823
原创 消息队列相关面试题
消息精准投递的核心是 “全链路可靠性 + 幂等性 + 有序性设计生产端靠 “确认机制 + 重试” 确保消息发出；队列靠 “持久化 + 集群” 确保消息不丢；消费端靠 “手动确认 + 死信队列” 确保处理成功；全链路靠 “唯一 ID + 幂等处理” 避免重复；有序性靠 “单分区 + 单线程消费” 保证。需根据业务对 “一致性” 和 “吞吐量” 的要求，灵活调整方案（如非核心业务可降低可靠性要求以提升性能）。
2025-09-08 03:20:58
1418
2
原创 线上问题排查相关面试题
线上死锁排查的核心流程是：“观察症状→获取线程快照→分析死锁线程和资源→结合代码定位原因→修复并验证”。其中，jstack命令是最直接有效的工具，能快速定位死锁线程和锁资源，结合代码分析即可找到问题根源。日常开发中，建议通过代码评审（检查锁获取顺序）和压力测试（模拟高并发场景）提前发现潜在死锁风险。用thread命令确认是否存在死锁，获取死锁线程 ID；用thread -b详细查看死锁线程的持有锁、等待锁及代码位置；用jad命令查看具体代码，分析锁的获取顺序或资源竞争逻辑；
2025-09-07 01:52:21
1720
原创 死锁相关面试题
死锁是多线程资源竞争的 “顽疾”，其发生必须同时满足互斥、持有并等待、不可剥夺、循环等待四个条件。实际开发中，无需过度担忧死锁（合理设计即可避免），但需掌握 “固定资源获取顺序”“一次性获取资源” 等核心规避手段，同时学会用工具检测死锁问题。预防死锁的关键是从设计层面避免死锁的四个条件同时成立按固定顺序获取资源（简单易实现，适合多数场景）；一次性获取所有资源（灵活性稍差，但能彻底避免 “持有并等待”）。实际开发中，应根据业务场景选择合适的方案，优先通过设计规避死锁，而非依赖运行时的检测与恢复。
2025-09-06 23:37:34
487
原创 线程相关面试题
操作系统的 7 种状态是内核级的细粒度划分，聚焦于 “线程与 CPU、资源的交互细节”（如就绪 / 运行的区分、阻塞与等待的差异）；而 Java 的 6 种状态是应用级的抽象，屏蔽了底层调度细节，方便开发者聚焦于 “线程的活跃性问题”（如为什么线程不执行、是否死锁）。理解两者的对应关系，能帮你更深入地掌握线程的生命周期本质。运行状态的线程绝对不可能一直占用 CPU操作系统的抢占式调度（时间片 + 优先级）会强制打破独占，保证 CPU 资源的公平分配；线程自身的阻塞、等待、I/O 操作等行为。
2025-09-06 22:29:48
781
原创 ThreadLocal相关面试题
ThreadLocal 适合解决 “线程内需要共享数据，但线程间需要隔离数据” 的场景，核心价值是简化线程内数据传递，避免线程安全问题。ThreadLocal 异步传递的核心陷阱是 “线程切换导致数据丢失” 和 “线程复用导致污染”优化的关键是 “主动复制上下文到新线程并及时清理”。根据场景选择手动传递、线程池包装或框架工具（如 TTL），可以有效解决这些问题。当你需要把线程 A 的文件（上下文）传递给线程 B 时，TTL 会在任务提交时 “拍照存档”（快照）。
2025-09-05 02:37:41
593
原创 TCP相关面试题
三次握手：建立连接，确保双方都能收发数据，是 “请求→确认 + 请求→确认” 的过程。四次挥手：断开连接，允许一方先结束发送，另一方处理完剩余数据再结束，是 “请求断开→确认→请求断开→确认” 的过程。这两个过程就像现实中 “先确认能沟通，再开始聊天；聊完了，确认双方都没话说了再挂电话”，保证了 TCP 传输的可靠性。
2025-09-04 22:07:42
325
原创 1. 两数之和
本文介绍了一种使用哈希表优化"两数之和"问题的解法。通过构建哈希表，将查找互补数的时间复杂度从O(n)降至O(1)，整体时间复杂度从暴力解法的O(n²)优化到O(n)。解题过程是遍历数组，检查当前元素的互补数是否存在于哈希表中，存在则返回结果，否则将当前元素存入哈希表。该方法的空间复杂度为O(n)，用于存储哈希表键值对。Java代码展示了具体实现，通过一次遍历即可高效解决问题。
2025-09-02 01:57:20
322
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人