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确实不好改掉。

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

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

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

posted @ 2017-03-29 08:45 涵s 阅读(...) 评论(...) 编辑 收藏