第一期：新项目内容框架来啦！
为了让更多小伙伴方便了解拿个offer社群近期的更新内容，我想了个主意——InfoWeek！通过这种形式，不仅能展示最新更新，还会分享一些我觉得有意思的思考和技术时事。
内容更新
1. oneThread 框架目录定稿
很多同学问：“马哥，咱们星球的三个业务系统都很棒，但怎么没有一个轮子系统呢？” 这不就来了～
新框架为动态线程池项目，代号为 oneThread，属于是 one 家族的第二个内部系统。
关注我的朋友可能知道，我主导开源的动态线程池中间件 Hippo4j，已在众多企业实战场景中广泛落地应用。这次开发新项目中的动态线程池功能，可谓是我的“看家本领”。
为便于大 家学习和理解，我对功能做了精简，移除了多余的适配模块，聚焦于线程池的动态调参、运行时监控及告警能力，帮助大家更高效地掌握核心机制。
oneThread 课程目录定稿版如下所示：
- 项目介绍
- 什么是oneThread动态线程池？
- 如何把oneThread动态线程池写到简历上？
- 第1部分：线程池基本概念
- 线程池知识点之什么是阻塞队列
- 企业中常见的线程池应用场景
- 深度解析线程池底层原理
- 为什么需要动态线程池？
- 第2部分：从零到一开发
- 如何设计oneThread动态线程池
- 如何自定义SpringBoot-Starter基础组件？
- 自定义动态线程池基础类
- 动态线程池参数动态替换机制
- 通过Nacos实现线程池参数配置
- 实现线程池参数动态刷新机制
- 实现阻塞队列容量热更新策略
- 通过Apollo实现线程池参数配置
- 基于模板方法的多配置中心抽象层设计
- 第3部分：线程池监控和报警
- 开发线程池阈值触发告警规则
- 基于动态代理模式完成线程池拒绝策略报警
- 通过Actuator实现动态线程池Metrics监控上报
- Prometheus配置oneThread运行时监控数据采集
- Grafana看板开发（线程池健康度仪表盘）
- 第4部分：动态线程池扩展
- 查看线程池运行时堆栈
- Tomcat线程池动态适配方案
- 通过回调函数实现线程池任务防丢失功能
- oneThread动态线程池框架Banner自定义规范
- 开发oneThread动态线程池前端控制台
- 第5部分：面试部分
- 动态线程池常见问题收集
- 如何把线程池基础组件推送Maven公共仓库？
目前已进入系统架构设计和编码阶段，完成后会优先把代码开放出来供大家学习，过程中持续完善项目对应文档教学。
2. 12306 更新内容列表
在 12306 的基础上，打造了一个增强版——12306Plus。这个版本不仅优化了接口性能，还新增了企业级实战专题。当然，12306Plus 不仅限于以下功能，后面还会源源不断新增诸多亮点实战。
本期更新目录如下所示：
技术周刊
1. 大厂开启动态线程池造轮子工程
继美团发布动态线程池 Rhino 后，并发布了一遍文章详细介绍，开源社区和各大企业公司开启了新一波的造轮子工程。
从企业角度来看，目前已有两家公司发布了关于动态线程池或线程池扩展的方案，各具优势。企业可以借鉴这些方案的优点，结合自身需求，集众家之所长，优化线程池管理。
2. Java24 版本发布
2025 年 3 月 18 日 Oracle 正式发布 Java 24，不过也和 Java 21 一样属于非长期支持的版本，包括之前的 JDK22 和 JDK 23。
下一个长期支持（LTS）版本是 Java 25，预计于 2025 年 9 月发布。目前，企业中仍以 Java 8 为主，但越来越多的企业已升级至 Java 17，不少开源框架也相应提升了 Java 版本。可以预见，Java 版本的升级将成为行业趋势。
3. Kafka 发布 4.0 架构，彻底移除 Zookeeper
Apache Kafka 4.0 的发布标志着其架构的重大革新，彻底移除了对 ZooKeeper 的依赖，转而采用内置的 KRaft 模式（基于 Raft 共识协议）实现元数据管理。这一变化简化了集群部署和运维，消除了维护独立 ZooKeeper 集群的复杂性，显著降低了运营成本，并提升了系统的可扩展性和稳定性。KRaft 模式下，元数据通过内置的 __cluster_metadata 主题存储，由选举产生的控制器（Controller）统一管理，通过事件驱动模型实现快速元数据同步和故障恢复，将大规模集群的恢复时间从分钟级优化至秒级。
此外，Kafka 4.0 引入了 KIP-848 消费者组协议，支持增量重平衡，减少停机时间，并新增共享组（Share Group）功能，允许同一分区的消息被多个消费者并行处理，突破传统分区与消费者一对一限制，支持点对点队列语义，扩展了 Kafka 在多样化场景中的应用。
4. ElasticSearch Star 被恢复
Elastic 公司发现其 GitHub 上的 ElasticSearch 仓库及旗下多个项目（如 Kibana）突然无法访问，显示 404 错误。调查确认，事故原因为内部操作失误，误将公开仓库设置为私有状态，导致所有用户无法访问，GitHub 自动清空 Star 记录。原 7 万余 Star 数被清零。
这件事再次验证了世界是个草台班子。Star 被清零后持续了一段时间，截至发稿，ElasticSearch 官方经过与 GitHub 沟通，已将 Star 恢复至 7 万。