- 博客(15)
- 收藏
- 关注
RSS订阅原创 SQL 优化实战指南：从定位瓶颈到架构升级
SQL 优化是一个 “由浅入深” 的过程：从定位慢查询、分析执行计划，到优化索引和语句，再到事务调优与架构升级，需结合业务场景灵活运用。核心原则是：减少数据扫描范围、降低 IO 开销、平衡一致性与性能。希望本文的实战经验能帮你在实际开发中少走弯路，让数据库性能更上一层楼！
2025-11-27 20:40:35
1975
原创 LeetCode经典题解: 矩阵
矩阵是由m行n列元素组成的二维数据结构，通常用二维数组表示。例如一个3x3[1, 2, 3], // 第0行[4, 5, 6], // 第1行[7, 8, 9] // 第2行。
2025-10-29 16:32:53
1459
原创 移动零: 从数组特性到双指针实战
理解数组连续存储的特性，才能意识到 “减少移动” 的重要性；掌握双指针的分工逻辑，才能把低效解法优化到 O (n) 时间复杂度；注意 Java 的细节（如空指针处理、数组长度获取），才能写出健壮的代码。
2025-10-28 14:11:03
1839
原创 LeetCode 经典题解: 滑动窗口
给定一个字符串s，返回其中不包含重复字符的最长子串的长度。子串：连续的字符序列（区别于子序列，子序列可非连续）；无重复：子串中任意两个字符的 ASCII 值或 Unicode 值不同；（需考虑空字符串、超长字符串场景）；输出：非负整数（最长子串长度，若s为空则返回 0）。# 1. 初始化窗口工具（根据约束选择：集合/哈希表/计数器）window_tool = set() # 示例：无重复约束用集合left = 0 # 左边界。
2025-10-25 11:39:02
1872
原创 LeetCode 三数之和：双指针思想的进阶实战指南
三数之和的双指针解法，本质是 “排序定方向，固定降维度，指针缩范围它不仅是一道题的解法，更是一种解决 “多数之和” 问题的通用思维 —— 当遇到需要遍历多轮、且数据可排序的问题时，不妨想想：能否用双指针将多轮遍历简化为单轮遍历？
2025-10-24 19:50:04
1833
原创 LeetCode 经典题解：两数之和 (哈希启动 ! ! ! )
暴力解法的问题在于 “内层循环查找元素” 的效率太低 —— 每次找 “能和当前元素凑成目标值的元素”，都要重新遍历一遍剩余数组。如果能把 “查找” 的效率提上去，整体性能会有质的飞跃。对于当前遍历到的元素nums[i]，如果存在一个元素nums[j]能和它凑成target，那么。我们把这个nums[j]称为 “补数”。哈希表最多存储n-1个元素（因为找到答案时就会停止遍历，不会存储所有元素），最坏情况下（答案在数组最后两位）会存储n-1个元素，因此空间复杂度是 O (n)。
2025-10-23 14:14:23
1403
原创 Activiti7 实战指南：从流程定义到任务管理，轻松搭建灵活工作流
简单说，工作流就是 “工作的流程”。员工填写申请→部门主管审批→人事归档申请人提交→部门经理审核→财务打款。这些固定步骤的业务流转，都可以称为工作流。硬编码依赖严重：流程步骤、审批人、状态流转全靠代码逻辑控制，比如用status=1表示 “待部门审批”，status=2表示 “待总经理审批”，一旦流程变更，就要修改大量if-else和状态判断。灵活性极差。
2025-10-21 17:22:33
643
原创 SpringCloud Alibaba 链路追踪实战：Sleuth+Zipkin 可视化链路
微服务链路追踪不是 “可选功能”，而是 “必备基础设施”。用 Sleuth 为微服务生成追踪日志，标记 Trace ID 和 Span ID；用 Zipkin 收集日志，可视化展示调用链路；通过链路追踪快速定位问题、优化性能。下次再遇到微服务调用的 “疑难杂症”，别再逐个查日志了 —— 打开 Zipkin，一次请求的完整 “足迹” 全在你眼前！
2025-10-20 15:03:48
1594
原创 拆解 Java 反射机制 —— 框架背后的 “灵魂” 特性
Java 反射机制是 “看似不用，实则离不开” 的核心特性 —— 它让程序从 “编译时固定” 走向 “运行时灵活”，成为框架设计的灵魂。虽然有性能和安全的小瑕疵，但只要合理使用（比如框架底层封装，避免频繁调用），就能最大化它的价值。
2025-10-18 09:57:50
1109
原创 别让索引拖垮性能！3 个判断标准，教你建对索引不踩雷
其实索引没那么复杂，核心就是 “帮数据库快速定位数据”，但关键在 “合适”：该建的地方别漏，不该建的别瞎建，类型选对，避开那些坑。平时多看看慢查询日志，看看哪些 SQL 没走索引，多踩几次坑（别线上踩），慢慢就有经验了。最后给大家个小建议：建索引之前，先想清楚 “这个索引是给谁用的？查什么条件？更新频繁吗？”，想明白这三个问题，基本就不会错了。
2025-10-17 22:08:21
1487
原创 微服务网关：为什么它是架构的 “必经之门”？（概念 + 痛点 + 解决方案）
网关看似不处理业务，却是微服务架构的 “必经之门”—— 它解决了客户端调用分散、认证重复、服务保护等核心痛点，让微服务更易维护、更稳定。后续还可以基于这个基础网关扩展：比如集成 Sentinel 实现网关限流、添加全局过滤器做统一鉴权、配置动态路由（不用重启网关就能修改规则）。如果你的项目正在做微服务拆分，网关一定要尽早规划，避免后续返工。
2025-10-17 14:41:21
1107
原创 深入浅出 Sentinel：微服务架构下的流量防卫兵
当 Sentinel 触发规则限制时，默认返回 “Blocked by Sentinel (flow limiting)”，可通过实现接口自定义异常返回格式，支持区分限流、降级、授权等不同异常类型。java@Component@Overridedata = new ResultData(-1, "接口被限流了");data = new ResultData(-2, "接口被降级了");data = new ResultData(-3, "参数限流异常");
2025-10-16 15:00:25
869
原创 Redis 开发运维踩坑与优化心得：从键名到持久化的实战总结
Redis 是内存数据库，一旦宕机，数据全靠持久化恢复，这一块可不能马虎。之前有个项目没做好持久化，服务器断电后，近 30 秒的数据全丢了，还好不是核心业务，不然损失就大了。Redis 有两种基础的持久化方式：RDB 和 AOF。RDB 是生成全量快照，优点是文件小、恢复快，但可能丢失快照后的所有数据；AOF 是记录所有修改指令，重启时重放，数据安全性高，最多丢 1 秒的数据（fsync 设为 everysec），但文件大、恢复慢。
2025-10-15 22:26:09
1303
原创 解决微服务两大痛点！Nacos 超通俗指南：服务自动发现 + 配置集中管，跟着做准没错
管服务：不用记 IP 端口，服务挂了自动剔除，新服务加进来自动识别；管配置：配置集中存，改了不用重启，重复配置能共享；还能帮其他组件存规则，避免重启丢配置。不用装多个工具（比如以前用 Eureka 管服务、Config 管配置），一个 Nacos 全搞定，对开发和运维都友好。
2025-10-15 15:28:19
1290
原创 注册中心：微服务的 “通讯录管理员”
没有注册中心，微服务就是 “一盘散沙”—— 服务之间找不到对方，地址改了全乱套，故障服务没法剔除。而注册中心通过 “管地址、查健康、同步信息”，解决了微服务通信的核心问题，是微服务架构里必不可少的 “连接器”。其中 Nacos 因为 “功能全、易集成、支持配置中心”，成为现在国内微服务的首选，实际项目里只要按 “装 Nacos→加依赖→配地址→注册调用” 的流程走，就能快速搭建起服务注册发现体系。
2025-10-15 15:08:42
825
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人