Spring 工程实践中的隐式规则：数据访问、事务、HTTP 调用与测试的常见陷阱

Spring 工程实践中的隐式规则：数据访问、事务、HTTP 调用与测试的常见陷阱Spring 最大的优势，是把大量底层细节包装成统一、易用的抽象；Spring 最容易让人踩坑的地方，也恰恰来自这些抽象。 很多问题看起来互不相关：Redis 明明写进去了却读不到、事务抛了异常却没有回滚、内层事务明明被 try-catch 了却把外层事务一起回滚、切换数据源的注解看起来执行了但 SQL 仍然落在原库
Java > Spring
#Spring Boot #Spring #Redis #AOP #Spring Data #Spring Transaction #RestTemplate #Spring Test #Cassandra

Spring MVC 请求处理全链路：从 URL、Header、Body 到 Validation、Filter、Security 与异常处理

从一次 HTTP 请求在 Servlet 容器中的完整生命周期出发，系统梳理 Spring MVC 的 URL 匹配、参数解析、Header、Body 编解码、Validation、Filter、Spring Security 与异常处理机制，并结合源码调用链解释常见错误、排查方法和现代 Spring 的版本演进。
Java > Spring
#Spring Boot #Java #Validation #Spring Security #Spring MVC #HTTP #Exception #Servlet #Filter

从 Bean 到 Web 请求：Spring 核心运行机制、AOP、事件与常见陷阱

Spring 好用的地方，恰恰也是它最容易让人掉坑的地方：大量重复、繁琐的对象创建、依赖装配、生命周期管理、代理增强和 Web 请求分发工作都被框架接管了。开发者只需要写几个注解，程序往往就能运行；但一旦包结构、Bean 数量、代理方式、初始化时机或监听体系发生变化，那些平时看不见的约定就会突然暴露出来。 理解 Spring，不能只停留在“这个注解怎么用”。更有效的方式，是建立一条完整的运行链路：
Java > Spring
#Spring Boot #Spring #Spring MVC #AOP #IoC #DI #Bean #ApplicationEvent #DispatcherServlet

安全编码体系：从信任边界、最小权限到纵深防御

安全编码体系：从信任边界、最小权限到纵深防御软件安全很容易被误解成“安全团队的工作”：防火墙、WAF、杀毒软件、漏洞扫描器、入侵检测、零信任网关都部署好了，应用似乎就安全了。 真正进入代码层以后，会发现事情恰好相反。很多严重安全事故的起点并不是一段“看起来像黑客代码”的实现，而是一次普通的字符串处理、一次整数加法、一次数组遍历、一次异常打印、一次对象序列化，甚至只是调用了一个自己没有真正理解的 A
软件工程
#Java #安全编码 #Secure Coding #Software Security #代码质量

Java 经济代码：从线程同步、内存管理到异步与可伸缩性的性能工程实践

Java 经济代码：从线程同步、内存管理到异步与可伸缩性的性能工程实践所谓“经济的代码”，并不是把每一行代码都压榨到极致，也不是看到 synchronized、对象创建或集合就条件反射式地“优化”。它讨论的是一个更完整的问题： 在满足真实需求的前提下，让软件用尽可能少的代码复杂度、线程协调、内存、CPU、I/O、状态和维护成本，完成尽可能多的有效工作，并为未来的规模增长留下空间。 如
软件工程 > 性能工程
#Java #并发编程 #性能优化 #代码设计 #内存管理 #异步编程 #可伸缩性 #JMH

高质量软件工程实践：从接口契约、文档与代码规范，到性能工程和简单设计

高质量软件工程实践：从接口契约、文档与代码规范，到性能工程和简单设计写出“能运行”的代码并不难，真正困难的是让代码在一个长期演化的软件系统中依然能够被别人理解、被安全修改、被可靠复用，并且在真实负载下以合理的成本运行。 从这个角度看，接口规范、用户指南、编码规范、Code Review、回归测试、性能工程、需求控制和接口设计，并不是彼此割裂的主题。它们实际上围绕着同一个目标展开：降低软件生命周期中
软件工程 > 性能工程
#Java #技术文档 #Code Review #API设计 #代码规范 #性能工程 #软件设计

RFC 2 带读：Host Software——从 RFC 1 的草图走向可实现的主机协议

前言RFC 1 刚刚提出“Host Software 应该怎么做”两天左右，SRI 的 Bill Duvall 就给出了 RFC 2。 两篇文档的标题都被 RFC Editor 收录为 Host software，讨论的也是同一批问题，但风格明显不同。 RFC 1 更像一张设计草图：它解释为什么需要 Host-to-Host Software，提出把 Link 0 留给控制消息，用其他 Link
RFC > 网络协议
#RFC #ARPANET #Host Software #IMP #NCP #Host-Host Protocol #SRI

Linux 性能优化工程方法论：从全局观到诊断闭环

Linux 性能优化工程方法论：从全局观到诊断闭环性能问题最麻烦的地方，通常不是“不会用某个命令”，而是不知道应该先看什么、为什么看、看到异常之后如何继续向下追。 线上出现延迟升高、吞吐下降、平均负载异常、CPU 打满、磁盘 I/O 抖动或者网络请求变慢时，如果排查方式仍然是“看一眼 top，猜一下最近改了什么，不行就搜索报错”，那么偶尔也能碰巧解决问题，但很难形成稳定、可复用的工程能力
Linux
#Linux #性能优化 #perf #性能分析 #Wireshark #系统原理 #网络

Linux 性能工程实战：从监控、定位、动态追踪到容器与网络调优

Linux 性能工程实战：从监控、定位、动态追踪到容器与网络调优Linux 性能问题真正困难的地方，通常不是“不知道某个命令怎么用”，而是不知道应该从哪里开始、下一步看什么、看到异常后如何把指标与系统机制对应起来。 CPU、内存、磁盘 I/O、网络只是性能问题的表象分类。进入真实系统后，一个看起来像“网络慢”的问题，可能来自连接跟踪表耗尽；一个“容器启动慢”的问题，可能并不是 Docke
Linux > Performance
#Linux #Docker #性能优化 #perf #性能分析 #eBPF #Prometheus #可观测性 #FlameGraph #网络调优

Linux 性能工程实战：从容器、网络丢包、动态追踪到监控与系统化优化

Linux 性能工程实战：从容器、网络丢包、动态追踪到监控与系统化优化Linux 性能问题真正困难的地方，通常不是“不知道某个命令怎么用”，而是面对一个模糊现象时，不知道应该观察什么、怎样把现象映射到系统原理、如何逐层缩小范围，以及优化之后如何证明问题真的解决了。 容器启动慢、服务间歇性丢包、ksoftirqd CPU 占用高、Nginx 吞吐量骤降，看起来是完全不同的故障。把这些问题放到一起，会
Linux > 性能优化
#Linux #Docker #性能调优 #perf #性能分析 #eBPF #网络性能 #Prometheus #可观测性

Linux 网络性能全景：从协议栈、C10K 到 NAT、抓包与内核调优

Linux 网络性能全景：从协议栈、C10K 到 NAT、抓包与内核调优Linux 网络性能问题很少是单点问题。 一个看起来只是“接口变慢”的故障，可能发生在 DNS 解析、TCP 建连、套接字缓冲区、协议栈、软中断、网卡队列、NAT 连接跟踪，甚至应用程序自己的 I/O 模型中。也正因为如此，网络性能分析不能只靠某一个命令，更不能看到 CPU 高就立刻调 CPU，看到延迟高就直接改 T
Linux
#Linux #性能优化 #Network #TCP/IP #epoll #Netfilter #NAT #tcpdump #Wireshark #DPDK #XDP

RFC 1 带读：Host Software——互联网协议协作从这里开始

前言如果只看标题，RFC 1——Host Software——很容易让人失望：它既不是 TCP，也不是 IP，没有我们今天熟悉的端口、三次握手、路由表，更谈不上 HTTP。 但如果把时间拨回 1969 年 4 月 7 日，它的重要性就完全不同了。 当时 ARPANET 甚至还没有正式投入运行。负责网络交换设备的 **BBN（Bolt, Beranek and Newman）**正在定义 IMP（I
RFC > 网络协议
#RFC #ARPANET #Host Software #IMP #NCP #网络协议

SQL 数据处理全链路：从数据清洗、ETL 到零售关联分析

在日常开发中，我们经常把 SQL 理解成“增删改查”的工具。但如果把视角从单个业务系统拉高到整条数据链路，会发现 SQL 实际上贯穿了数据的产生、清洗、集成、分析和展示。 一条比较完整的数据处理链路可以概括为： 1234567891011121314151617业务系统（OLTP） │ ▼数据抽取 Extract │ ▼数据清洗 / 转换 Transform
数据库
#Redis #SQL #SQLite #OLTP #OLAP #数据清洗 #ETL #Kettle #Python #Apriori