Java

浏览该分类下的所有文章

Kubernetes1.37升级审计清单：网络、资源、安全、存储一次说清

Kubernetes 1.37 的重点并非新增大量业务功能，而是推动 IPVS、cgroup v1 等旧基础设施路径退场，并加强 SELinux 卷挂载、Metrics API、Rootless kubelet 和存储健康监测。本文从 Java 服务视角分析这些变化对 Service 网络、JVM 资源识别、Static Pod、共享 PVC、HPA 和节点安全的影响，同时提供可直接执行的集群、节点与 Java 工作负载审计命令，以及分阶段升级和回滚思路。

2026-08-24 22:23:30 阅读

从依赖扫描到可信发布：Java 项目软件供应链安全实战

传统 Java 项目往往只关注依赖漏洞，却忽略了依赖解析、CI 构建、制品存储和部署替换等供应链风险。本文从工程实践出发，讲解如何使用 CycloneDX Maven Plugin 生成 SBOM，利用 Trivy 扫描漏洞与许可证，通过 Cosign 为镜像签名并绑定 SBOM Attestation，再结合 SLSA Provenance、VEX 和策略门禁建立可验证的发布链路。同时分析 SBOM 与最终镜像差异、签名密钥隔离、例外审批、历史清单归档和持续重扫等生产落地问题，帮助 Java 团队将发布流程从“默认信任”升级为“基于证据验证”。

2026-08-22 23:03:13 阅读

抖音续火花助手：支持定时发送、网页管理和登录态更新

抖音续火花助手是一款面向个人用户的开源自动化工具，可部署在自己的服务器上，每天定时向指定好友发送续火花消息。项目提供可视化网页后台，支持好友与消息管理、登录态上传、联系人同步、干跑测试、立即发送、任务停止、结果记录和日志查询。同时具备会话校验、搜索兜底、发送确认、限流识别、超时终止和浏览器回收等保护机制。项目基于FastAPI、Playwright和Vue开发，支持Python及Docker部署，并提供Windows登录态更新工具，适合个人低频自用和自动化技术学习。

2026-08-22 18:21:59 阅读

GitHub可用性改造背后的故障隔离真相

本文指出，系统出现性能问题或故障后，团队常倾向于拆微服务、上 Kubernetes、增加机器，但这些手段不会自动带来高可用。GitHub 2026 年可用性改造的真正主线不是增加服务数量，而是持续移除共享故障点，把故障限制在更小范围。微服务数量不等于故障隔离，真正隔离包含代码边界、资源边界和故障边界。GitHub 通过迁出认证权限、让仓库与 Pull Request 使用独立基础设施、降低单机房依赖，逐步建立隔离。文章提出可靠性改造五原则：识别核心用户路径、优先隔离资源、主动丢弃负载、逐步放量快速回退、高可用不等于所有功能正常。中小团队可先画依赖关系、识别共享资源、建立软隔离，再拆分高风险域。真正架构升级是控制故障传播，拆服务前应问：模块失控后，能否只让自己失败？

2026-08-19 11:45:56 阅读

别只加索引了：PostgreSQL 18底层性能变革解读

PostgreSQL 18 的性能优化不再局限于加索引或调 SQL，而是从底层重构数据访问与建模方式。其异步 I/O 子系统通过 worker 或 io_uring 并发读取，显著改善大表扫描、Bitmap Heap Scan 和 VACUUM 的吞吐；B-Tree Skip Scan 允许联合索引在缺失最左列时仍能部分利用；原生 UUIDv7 提供时间有序标识，提升索引写入局部性；虚拟生成列将确定性行内计算统一到数据库；增强的 RETURNING OLD/NEW 可一次获取修改前后数据。文章强调，这些能力并非自动加速所有查询，升级前应基于真实负载测试，合理配置 I/O 并发参数，并关注统计信息恢复与生态兼容。

2026-08-18 14:30:40 阅读

MCP协议大改之后：Java与Spring AI如何跨越兼容性断层

MCP 2026-07-28规范移除了初始化握手和协议级Session，转向每次请求自带版本与能力声明的无状态模型。当前Java MCP SDK 2.0.0和Spring AI仍基于2025-11-25协议，接入客户端时可能出现探测失败、未知方法返回500等问题。本文梳理新旧协议差异与Java生态现状，并给出兼容测试、状态外置、权限校验、协议网关和双栈灰度方案，帮助Java团队平稳完成MCP升级。

2026-08-15 08:54:19 阅读

AI接口能跑不等于可靠：如何建立回归评测与质量门禁

大模型接口返回 HTTP 200，并不代表回答正确。Prompt、模型、RAG、工具和参数的任何变化，都可能引发难以察觉的质量回归。本文基于 Java、JUnit 与 Spring AI 2.0，设计一套可落地的 AI 回归测试体系：使用版本化数据集管理正常、边界、对抗和历史失败样本，通过确定性规则拦截格式、安全、Token 与时延问题，再使用模型裁判评估正确性、事实一致性和相关性，并结合多次运行通过率、基线对比和 CI 质量门禁，让 AI 功能从人工聊天验收走向可量化、可回归、可持续交付。

2026-08-14 09:03:34 阅读

从ThreadLocal到ScopedValue：Java上下文传播正在改变

随着 Java 应用从传统 CRUD 走向 AI Agent，userId、tenantId、traceId、conversationId 等上下文需要在更复杂的调用链与并发任务中稳定传播。JDK 25 正式定稿的 ScopedValue，为“上游绑定、下游只读、任务结束自动失效”的场景提供了比 ThreadLocal 更清晰的语义。本文结合虚拟线程、结构化并发与 Spring AI ToolContext，分析 ScopedValue 的设计原理、适用边界、异步传播限制及安全注意事项，并给出 Spring Boot 项目的上下文分层与迁移思路，帮助开发者重新理解 Agent 时代的 Java Context 设计。

2026-08-13 10:52:22 阅读

从96%到70%

本文记录了把四个独立的 Spring Boot 项目（chat、puke、zepp、blog）合并为一个 Maven 多模块工程，只启动一个 total‑app.jar 的实践。原先每个项目占用一个 JVM，导致服务器内存接近 96%；通过在根 pom 统一依赖、在 launcher 中用 SpringApplicationBuilder 依次启动四个 ApplicationContext，并将配置分别放在 chat.yml、puke.yml、zepp.yml、blog.yml 中，消除了 JVM 底座的重复开销，内存降至约 70%。文章重点阐述了类路径冲突、资源目录重名、自动配置串扰和日志全局化等踩坑及对应的统一依赖、资源隔离、spring.autoconfigure.exclude 等解决方案。部署时仅需一次打包并用单条 java 命令启动，端口和 Nginx 配置保持不变，运维更简洁。该方案适合资源受限、访问量不高且对隔离要求不强的场景，虽牺牲了故障隔离，但能显著降低内存压力，为小型服务器提供务实的优化路径。

2026-07-13 18:00:23 阅读

从Demo到生产：Agent为什么需要Durable Execution

随着 AI Agent 从简单问答走向多步骤、长时间运行的企业任务，传统 HTTP 请求模型开始面临状态丢失、重复执行、重试失控、服务重启后任务无法恢复等问题。本文从 Java 后端视角介绍 Durable Execution 的核心思想，分析 Workflow、Event History、Retry、Timeout、Idempotency、Human in the Loop 等关键能力，并结合 Temporal 与 Spring AI 的集成，说明如何将模型调用、Tool Calling、MCP 和传统业务 Service 纳入可恢复、可重试、可审计的执行流程，帮助 Agent 从“能运行”真正走向“可生产”。

2026-08-12 08:54:47 阅读

MySQL8.0退场之后：Java项目该如何选择8.4LTS与9.7LTS

MySQL 8.0 已于 2026 年 4 月正式进入 EOL，大量仍运行在 8.0 上的 Java 项目需要重新规划数据库版本。与此同时，MySQL 9.7 已成为新的 LTS，因此升级问题不再只是“8.4 还是 9.x”。本文结合官方升级路径，从 MySQL 8.4 与 9.7 的选择、认证插件变化、Connector/J、TLS、Upgrade Checker、SQL 回归、备份和回滚等方面，给出一套适用于 Spring Boot 项目的实际迁移方案。对于存量系统，更稳妥的策略通常是先迁移到 8.4 LTS，在稳定运行后再根据生命周期决定是否继续升级 9.7 LTS。

2026-08-11 09:26:22 阅读

从CRUD到Agent：Java开发者如何构建企业级AI智能体系统

本文围绕 Java 企业开发从传统 CRUD 向 AI Agent 演进展开，介绍 Spring AI、Tool Calling、RAG、Memory、Workflow 等核心能力，并结合企业真实场景分析 Agent 如何连接现有 Spring Boot 业务系统。文章重点强调，企业 AI 的难点并不只是调用大模型，而在于权限控制、数据治理、操作审计、幂等设计、人工确认以及系统稳定性。未来 Java 开发者不需要抛弃原有技术体系，而是应在熟悉的 Service、数据库和业务架构之上增加智能层，让系统从“执行固定流程”逐步升级为“理解用户目标并主动完成任务”。

2026-08-10 22:28:01 阅读