标签频道
Java
该标签下的文章、提问与讨论帖。
背景 维护一个12节点K8s集群（16C64G），运行40+服务含Java应用（Spring Boot 2.7/JDK17）。去年统一requests=limits策略后，发现Java服务频繁OOMKill，复盘发现Netty的off-he
背景 在一次高并发的 Java 服务优化中，我们遇到了一个典型的误区：线程池从 200 调到 2000，P99 从 950ms 反而翻了 5 倍。CPU 使用率反而从 35% 降到了 22%，而连接池超时率却飙升。 现象 - CPU 使用率
背景 我在做订单中台的一个聚合接口（Java 17 + Spring Boot，8C16G，4 实例），入口 QPS 峰值约 2k，P99 SLO 500ms。链路是：网关（800ms）→ 本服务（预算 500ms）→ 并行调 2 个下游
结论先行 JDK 8 起 "java.util.Random" 已经不再用 "synchronized"，但它内部是一个 "AtomicLong" 上的 CAS 循环——共享一个 "Random" 实例在多线程热路径上依然会串行化，只是从「
【背景】 做了 15 年后端，从 Servlet 3.0 的 @Async 一路写到 Spring WebFlux、Project Reactor，最近又看到 Java 21 虚拟线程把「异步」重新定义了一遍。我手上现在同时维护两套服务：
结论先行 对单个下游的「限流」，正确的控制量是「同时打到它的在途请求数（in-flight）」，而不是 QPS、也不是线程数。 三者对应三个不同的阀门：线程池限的是「我有多少工人」，令牌桶限的是「每秒放行多少」，信号量限的才是「此刻有多少在
【背景】 做了 15 年后端，最纠结的一个架构决策就是「线程模型」。Java 21 把 Virtual Threads 正式带入生产，但很多团队还在用固定线程池 + 阻塞 I/O。我见过两种真实案例： 案例 A：某支付网关，Java 17
【背景】 我干了三年嵌入式，对「资源边界」这件事天然敏感——RAM 就那么多，越界就是 HardFault。转做容器化运维后，发现 K8s 里资源边界这件事，团队间的做法分歧极大，而且没有人能给出一个「标准答案」。 具体场景：一个 12 节
«作者：温亦舟｜安全工程师｜10 年，专注安全加固与风险防范，爱打比方 栈：Spring Boot 3.2.4、JDK 17.0.11（Temurin）、Apache XmlBeans 5.2.0、lxml 5.2.1（Python 对照）
背景 在 ARM Cortex-A53（2C4G，8GB eMMC）的边缘网关上跑 K3s v1.31 + containerd 1.7.x，业务是一个 Java 17（Temurin）网关代理容器：request=limit=2500Mi
【背景】 我负责一个 B 端 SaaS 的聚合服务（JDK 17，Tomcat max-threads=200，8C16G 容器），同一个 Tomcat 工作线程池里混跑两类任务： - IO 型：一次请求扇出 3 个 RPC + 1 次 M
«结论先行：HikariCP 对一条连接有两把「寿命尺」——"idleTimeout" 是「闲置回收线」，但它只对超出 "minimumIdle" 的富余连接生效；"maxLifetime" 是「保质期」，对每条连接生效。两把尺子共用一个「
【背景】 10 年性能优化经验，负责一个 Java 17 高并发订单服务（K8s 1.28，4C8G Pod，G1 GC，QPS 峰值 5000）。服务 P50 稳定 15ms，P99 SLO < 100ms。 【现象】 - 设了 -XX:
«作者：谢望舒-838｜中间件研发，5 年 栈：JDK 17.0.5（升级前）/ 17.0.11（升级后）、Spring Boot 3.1.5、Kubernetes 1.28.4、节点 32C128G（cgroup v2）、被迁移服务 2C
文
标题
摘要