首页
沸点
课程
APP
搜索历史
清空
创作者中心
写文章
发沸点
写笔记
写代码
草稿箱
创作灵感
查看更多
登录
注册
Java 后端核心知识图谱
梅头脑
创建于2026-07-15
订阅专栏
从 JVM 内存模型到分布式系统设计,13 篇深度文章覆盖 Java 后端核心知识体系。
暂无订阅
共17篇文章
创建于2026-07-15
订阅专栏
默认顺序
默认顺序
最早发布
最新发布
拆了20个微服务后每天都在救火——直到画出了这6大治理支柱,17篇正刊收官的最后一课
微服务治理六大支柱:发现/配置/网关/熔断/链路/网格 一、为什么需要微服务治理 单体拆成微服务后,从"一个进程内的方法调用"变成"跨网络的 RPC 调用",引入了一系列新问题: 单体时代 微服务时代
分片键选user_id还是order_id?选错一次,80%查询跨库,加班三周全量回滚——分库分表血泪决策指南
分库分表实战:垂直/水平分片 + ShardingSphere 5.x 一、为什么需要分库分表 1.1 单表的物理极限 MySQL 单表在 500 万行以下通常表现良好,超过 2000 万行后 B+T
学了6种设计模式却写出了同事看不懂的代码——SOLID五原则反例对照,治好了我的"过度设计"
设计模式:GoF 经典 + SOLID 原则实战 一、设计模式概述 1.1 三大分类 类型 说明 典型模式 创建型 隐藏对象创建逻辑,降低客户端与具体类的耦合 单例、简单工厂、工厂方法、抽象工厂、建造
Java镜像1.2GB→200MB,K8s Pod OOMKilled 137半夜报警——容器化的真实踩坑记录
容器与 K8s 核心知识:从 Docker 镜像分层到 Pod 调度 一、Docker 基础:容器不是"轻量级虚拟机" 1.1 容器 vs 虚拟机 维度 容器 虚拟机 隔离级别 进程级(共享宿主机内核
流量从1万到100万,每次加机器发现瓶颈只是往上挪了一层——负载均衡三层架构的演进实录
负载均衡与高可用:LVS + Nginx + Sentinel 三层防护架构 一、四层负载均衡与七层负载均衡 维度 四层(L4,传输层) 七层(L7,应用层) 工作层级 TCP/UDP,仅解析 IP
面试官问"TCP为什么三次握手不是两次"——我用一个生活例子+设计推导,他不再追问了
计算机网络基础:后端必知 TCP/HTTP/TLS 核心机制 阅读约 14 分钟 | 系列第 12/17 篇 一、TCP 三次握手 为什么是三次,而非两次? 两次握手存在一个关键缺陷:无法识别网络中滞
交易跨10个库、日均千万订单——选错一次分布式事务方案,加班三个月重写
分布式系统设计:CAP/BASE 选型 + 分布式事务四方案 + Raft 共识 一、CAP 定理:P 必须选,C 与 A 的权衡 CAP 定理:一个分布式系统最多同时满足 Consistency(一
日均百万笔支付,消息一条都没丢——RocketMQ三段式兜底方案,在生产环境跑了2年
消息队列:RocketMQ 金融级可靠性保障与架构原理 一、消息队列的核心价值 消息队列的核心价值可归纳为三个维度: 能力 含义 典型场景 空间解耦 生产者无需感知消费者的存在,只需将消息投递至 Br
@Transactional加了没回滚?排查了不下20次,总结出这张6种失效场景对照清单
Spring 框架核心:IoC 超级工厂 + AOP 代理 + @Transactional 六种失效场景 一、IoC:控制反转的本质 IoC 到底是什么? 反转的是什么? 对象的创建和管理权从"程序
ThreadLocalMap里几十万个死Entry——排查了半天OOM,根因就一行finally没写
Java 并发编程(三):ConcurrentHashMap + ThreadLocal + 实战 一、HashMap 为什么线程不安全? HashMap 在并发场景下三大问题: 1. JDK 7 死
背了"CPU核数+1"还是被面试官问倒?线程池7参数不是公式,是一条联动推导链
Java 并发编程(二):AQS 框架 + 线程池核心机制 一、AQS:JUC 并发包的骨架 AQS(AbstractQueuedSynchronizer)是 java.util.concurrent
写了3年CRUD,volatile和synchronized的区别还是答不清——直到我画出了这张三性两锁边界图
Java 并发编程(一):可见性/原子性/有序性 + volatile + synchronized 一、可见性、原子性、有序性——三个概念用同一个场景讲清 这三个概念是并发编程的根基。用一个生活场景
Full GC每10分钟一次、STW超2秒:我从CMS换到G1再到ZGC,STW降到了200ms
JVM GC 与调优:7 种垃圾收集器选型 + 参数调优实战 一、判断对象存活:两种算法 算法一:引用计数法 每个对象维护一个计数器,被引用一次 +1,引用失效 -1,归零即回收。 优点:实时回收,无
OOM排查别再全量dump分析了:记住JVM这6个区的溢出症状,按图索骥快10倍
JVM 内存模型:6 个运行时数据区 + 堆分代 + 对象生命周期 一、总体架构:6 区 + 1 JVM 规范定义了 6 个运行时数据区 + 直接内存,按线程私有/共享分为两大类: 逻辑 vs 物理
一条SQL从5秒到0.05秒:我拆开了B+Tree、MVCC和EXPLAIN,找到了慢查询优化的根
MySQL 数据库原理:从范式到 B+Tree,MVCC/行锁/EXPLAIN/Binlog 全链路 一、基础概念:从范式到 SQL 执行路径 1.1 三大范式与反范式 范式 要求 示例 1NF 列不
Redis 核心原理:为什么快?五种数据结构 + 持久化双引擎
一、Redis 为什么快? Redis 的快不是单一原因,而是四层叠加的结果。 第一层:纯内存操作 数据驻留在内存中,读写不经过磁盘,单次操作达到微秒级。这是最快的硬件基础。 第二层:单线程模型 Re
记一次大促前压测OOM:CPU飙到300%,靠3个命令定位到元凶
一、接口响应慢:分层排查体系 线上收到"接口变慢"的告警,最大的忌讳是一上来就猜测原因。标准做法是分层排查,逐层排除。 第一层:链路追踪定位 通过 SkyWalking / Zipkin / Jaeg