在高性能 Java 开发中，很多人关注的是算法、异步和锁。但很少有人意识到：日志系统往往是高并发系统的第一个“性能出血点” 。当你随手写下一行 System.out.println 时，你的系统响应时间可能已经悄悄翻了几百倍。
一、 拒绝“自残”：为什么原生输出是性能杀手？
在 JVM 层面，System.out 底层通常带有同步锁（Synchronized），且其 I/O 操作直接由当前业务线程承担。这意味着在高并发下：
- 线程阻塞：100 个请求同时打印日志，99 个在排队等锁。
- 内存风暴：每打一行日志都在
new StringBuilder，导致 GC 频繁触发，吞吐量断崖式下跌。
gzb one 的哲学：如果日志拖慢了业务，那就是日志系统的失职。
二、 核心黑科技：全链路异步化与零损耗设计
1. 物理级 Hook：强制异步化
gzb one 启动即接管全局：
Java
public static void installHOOK() {
System.setOut(new HOOK(1)); // 接管标准输出
System.setErr(new HOOK(4)); // 接管错误输出
}
通过 System.setOut 替换原始输出流，开发者随手写的 println 会被强行重定向到 gzb one 的异步队列中。同步阻塞瞬间变为“内存操作”，业务线程“甩包”即走，性能丝毫不降。
2. ThreadLocal 内存复用：零对象损耗
这是最极致的地方。gzb one 拒绝为每条日志创建 StringBuilder：
Java
GzbThreadLocal.Entity entity0 = GzbThreadLocal.context.get();
int index0 = entity0.stringBuilderCacheEntity.open();
StringBuilder sb = entity0.stringBuilderCacheEntity.get(index0);
// ... 处理日志 ...
entity0.stringBuilderCacheEntity.close(index0);
利用自研的线程实体缓存，所有日志拼接都在复用的内存空间中完成。这意味着无论你打多少日志，JVM 的堆空间几乎没有波动，彻底消灭了日志带来的 GC 压力。
3. 1MB 巨型缓冲区：批量持久化
日志不再“来一条写一条”，而是积攒到 1MB 缓冲区，通过 System.arraycopy 进行内存级搬运，最后由独立的服务线程进行批量磁盘写入。这让磁盘 I/O 吞吐量达到了物理极限。
三、 运维级的智慧：MD5 异常去重
生产环境最怕什么？异常刷屏。一个数据库连接断开，日志文件可能在几分钟内撑爆磁盘。
gzb one 内置了聪明的 MD5 指纹去重逻辑：
Java
String md5 = Tools.textToMd5(msg);
int num = Cache.gzbMap.getIncr("异常去重", md5, 60);
if (num > 1) {
msg = "异常已出现 " + num + " 次,异常MD5:" + md5;
}
60秒内相同的异常只记录一次详情，后续仅增加计数。这不仅保护了服务器磁盘，更让运维人员能一眼看到核心问题，而不是在海量重复日志中“大海捞针”。
四、 性能监控：自带慢 SQL 预警
gzb one 认为日志不只是记录，更应该是监控。在 LogImpl 中，SQL 耗时被自动分级：
- < 100ms：Debug 级别（绿色）。
- 100ms ~ 1000ms：Warn 级别（黄色）。
- > 1000ms：Error 级别（红色）。
你不需要查监控图表，看一眼日志文件的颜色，就能立刻定位到哪个接口需要优化。
结语
一个伟大的框架，体现在那些“看不见”的地方。gzb one 的日志模块不是一个简单的工具，它是一套经过深思熟虑的系统治理方案。
github:github.com/qq129736888…
gitee:gitee.com/gzb001001/g…
