PERSONAL BLOG · 技术随笔正在更新

你好呀,我是小邹

从Java出发,向系统深处走,也向AI时代延伸。这里记录技术实践、系统原理与工程思考——不止于把代码写出来,更试着把问题看明白。

“你羡慕的生活都是你没熬过的苦。”
41 归档分页
647 留言互动
14 核心专题

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。

Java开发者如何构建企业级AI智能体系统

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

2026年值得关注的7个技术变化

2026 年,Java 生态正在迎来新一轮技术升级。从 JDK 26 原生支持 HTTP/3、Virtual Thread 与 Structured Concurrency,到 Project Leyden 推进 AOT Cache,再到 JDK 27 在对象头压缩、垃圾回收、后量子安全和 JFR 脱敏方面的增强,JVM 正变得更高效、更安全。同时,Spring Boot 4.1 加强 gRPC、OpenTelemetry 等生产能力,Spring AI 2.0 则通过 Tool Calling、MCP 和 Agent 将 Java 深度带入 AI 时代。本文系统梳理 2026 年 Java 值得关注的核心技术变化,并给出新项目的技术选型思路。

PostgreSQL 18底层性能变革解读

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

JDK27如何用Compact Object Headers压缩整个堆

Java应用的内存浪费不只来自业务字段,每个对象携带的对象头也会在海量实例下形成开销。本文围绕JDK 27默认启用的Compact Object Headers,拆解传统与紧凑对象头的布局差异,解释少4字节为何影响堆占用、GC频率、缓存局部性和容器密度,并通过JOL展示变化。同时给出JDK 25、26的启用方式、灰度流程、监控指标、适用场景与风险边界,帮助团队在升级前完成可验证、可回滚的内存优化。

Netty4.2如何用io_uring重构网络I/O

Netty 4.2 将 io_uring 从孵化模块升级为正式传输实现,使 Java 网络服务能够通过提交队列与完成队列批量交付 I/O。本文从 epoll 的就绪模型讲起,拆解 SQ、CQ、multishot 与缓冲区环,给出 Maven 依赖、运行时探测、三级回退和调优示例,并说明它与虚拟线程的边界。文章还分析 Docker seccomp、内核开关、原生库分类器与压测误区,帮助开发者判断 io_uring 是否适合生产环境。

AI审核、AI回复与表情包系统

本文介绍个人博客中 AI 评论审核、AI 自动回复与表情包系统的完整设计。系统在评论安全入库后,通过异步任务执行本地敏感词预筛,并根据内容类型将普通文本、内置表情和斗图图片分流至文本或多模态模型。借助七种审核状态、条件更新和定时重试机制,避免并发覆盖、重复审核与回复丢失。AI 回复结合文章内容、评论语义和表情情绪生成个性化内容。表情包服务则通过域名白名单、URL 校验、HTML 清洗、缓存及故障降级保障安全与可用性,最终形成可恢复、可追踪、支持人工接管的评论治理流水线。

SpringBoot多模型路由、鉴权与计费安全实践

本文以多模型系统为例,指出付费大模型接入的关键不在接口调用,而在身份、模型、网络与成本边界。后端应建立统一出站层,集中完成认证校验、模型白名单、授权、端点验证及 Redis Lua 额度控制。Redis 异常时应拒绝付费请求,禁止自动重试和重定向;长连接使用租约心跳,结果不确定时不立即释放租约,避免重复计费。分享标题等隐式功能应固定使用免费模型并支持降级,以自动化测试固化权限、路由和异常处理规则。

Codex 实战指南

Codex 与普通补全工具不同,它能进入项目读取、修改文件、运行测试、解释报错,充当“会干活的 AI 搭档”。文章首先说明它最适合处理需要上下文理解的任务,如阅读陌生代码库、定位 Bug、补充测试、实现小功能等,并比较 IDE 插件、CLI 与云端三种使用方式,建议新手先从 IDE 或 CLI 入手。随后提供 macOS Homebrew 安装、账号或 API Key 登录步骤,并示例第一次只读分析项目结构,以低风险任务起步。针对 Prompt 编写,文章提出四要素(要解决的问题、修改范围、约束条件、验证方式),强调先让 Codex 写计划、提供充分上下文、要求自行运行测试并迭代修复。为统一项目规范,推荐在仓库根目录放置 AGENTS.md,记录依赖、lint、测试等规则,并通过 sandbox 参数控制只读、工作区写入或全访问权限。接着列举解释代码库、修复 Bug、实现筛选功能、补充测试、代码审查等常见场景,并说明使用 codex exec 实现自动化生成 release notes、总结 CI 失败等。云端任务适合大规模或并行操作,但仍需人工 Review。最后总结最佳工作流为只读分析→制定计划→小步修改→运行测试→人工 Review,提醒勿盲目信任结果,及时设定项目规则与权限,以让 Codex 成为提升效率而非取代程序员的可靠助手。