Spring+SpringMVC+MyBatis+easyUI整合优化篇（一）Java语言中System.out.print与Log的比较

作者：13
GitHub：https://github.com/ZHENFENG13
版权声明：本文为原创文章，未经允许不得转载。

前言

距离上一次更新博客有一段时间了，主要是因为最近有开发任务，另外，这段时间也在学习docker的相关知识，所以博客就没有继续写了，推荐一本书《Docker技术入门与实战》(第二版)，想体验一下docker的朋友可以看一下。

按照计划，第二阶段主要是讲一下项目优化上的一些东西，相关的工具已经在基础篇介绍了一些，所以在本阶段更多的是侧重于代码上，虽然做了一份粗略的计划，但是第一篇该写什么又犯了纠结，刚好有一次编写代码时看到一个方法中含有System.out.print()打印语句，这个方法大家都不陌生，第一份代码应该都是"世界，你好"，所以本篇就讲一下System.out.print与Log吧。

原因简述

提到代码优化呢，其实需要注意的有很多个地方，因为一个系统涉及到很多技术，针对每个技术也需要对应的优化方案，因此，这是一件时间跨度长且复杂的工程，所以优化篇的开始呢，就先从最开始的地方讲起，打印语句，可能我们每个人都会在日常编码过程中都存在的一个问题，就是对于程序中的一些输出信息，喜欢使用System.out.print打印到控制台上，而不采用日志记录的方式输出到对应的日志文件。

为什么要讲这个事情呢？因为这个问题其实我也想了挺久的，就是System.out.print和log的区别在哪，区别到底有多大，刚好看到代码里有一些System.out.print代码，所以今天就写了这篇文章。

System.out.print与Log比较

• System.out.print的优点：直观、方便。

• Log的优点：异步、解耦、灵活、策略多。

• 提到System.out.print，除了感觉到方便之外，还会想到其他的优点吗？似乎也就这个优点，syso快捷键瞬间就是一条打印语句，很顺手的一件事，除了这个感觉外，似乎也没有其他特别的感受了。

• System.out.print和java运行程序运行在同一线程，也就是说，业务程序会等待System.out的动作，导致资源被占用，log4j、logback等日志工具进行调试信息的打印，这类工具是异步线程的，不会使程序处于等待状态。

• System.out.print是在控制台输出，只能输出到控制台，功能上线后，总不能一直盯着控制台吧，而且日志文件需要保留，以供日后分析，是需要一套管理规范的，即便使用tomcat服务器，System.out会输出到catalina.out文件，catalina.out文件也不会一直存在，需要定期清空，如果不清空，大文件的读写也是挺影响性能的。说到这里，System.out.print写入的文件只有一个，对于一个文件的读写，这个io肯定会排队写，且System.out.print在当前线程，肯定对性能会有稍微的影响。

• 程序中充斥着大量的System.out.print打印代码是相当不规范的。

补充说明

当然，说到影响服务器性能，必须是代码中存在大量的System.out.print才会明显的影响，而这个量需要有多大呢？考虑到系统体量、服务器版本、服务器配置这些因素，很难给一个固定的值，而且肯定也有很多人认为小量的不规范代码不会使人察觉的，我也支持这个观点，不过我们也要记得一句话，千里之堤溃于蚁穴，不能因为一件事是小事就选择性忽略掉，对自己要求高一点，写的代码也一定要整洁且正确。

项目由小项目慢慢成长为大项目，对于系统的日志要求肯定也越来越苛刻，后期肯定也要搭建日志系统的，日志信息的采集和分析也肯定是用对应的Log框架及相关的技术去做，比如ELK技术栈，这个时候，再问自己一个问题，在控制台上打印是怎样的一种感受呢？

针对于日志的灵活性，根据一些日志框架的特点，也可以定制自己的日志规范，日志输出策略、日志存储策略、日志维护策略，想怎么输出怎么输出，想怎么存储怎么存储，非常的灵活。不同团队根据自己团队的特点制定出自己的日志策略，而不是一味的System.out.print打印到控制台上，与此相比，程序中充斥大量的System.out.print语句明显黯然失色。

以上为个人观点。

总结

今天讲这个事情，主要的原因，是因为有一次在查找System.out.print和log的区别时，发现网上并没有介绍这个问题的文章，所以就自己整理了一下。另外一个方面，是觉得代码规范这个事情还是很重要的，希望大家日常编码工作中注意，并没有其他的意思，因为其实写顺手了，System.out.print确实不好改掉。

这里引用代码整洁之道中的一句话：

“进度可以重订，需求可以修改，团队动态可以修正，但糟糕的代码只是一直腐败发酵，无情的拖着团队的后腿。”

这里所讲的糟糕的代码，不只是不规范的输出语句，也包括了很多其他方面不规范和不整洁的代码，改掉不良习惯，养成良好的编程习惯，共勉。