我们在写程序时，格式化时间是家常便饭。

我们知道，通常的格式有yyyy-MM-dd HH:mm:ss。
那么毫秒呢？
是sss还是SSS？

哈哈，时间格式里，压根没有sss。

也就是说，毫秒是用SSS来表示的。

------------------------------ 分割线 ------------------------------

话说，这个sss可把我困惑很久了。

我们的系统用的日志框架是log4j。
最近随着交易量的增大，我在观察线程池任务处理情况时，总是奇怪的发现，一个请求链路记录的log里，竟然是同一毫秒。
按说不应该呀，一个请求链路有包括方法调用、rpc调用、db读写。这么一串操作下来，怎么说也得超过1毫秒呀！

今天和同事分析线程池里的active任务。

出于对log4j这个时间的疑惑，我们程序里在打印log的地方加上了当时的时间戳。即：

重新部署之后，发现log4j所打印出来的时间跟我们的时间还真不一样。

莫非是log4j的问题？
我们知道，log4j、logback这些日志框架是异步记日志的。那么，是不是说，log4j在异步“批量”记日志的时候，所打印的时间是记日志时的时间呢？按道理来讲，log4j不能这么弱吧，应该是我们的应用程序调用slf4j的api时的时间才对呀！

我曾有意无意地看过应用里log4j.properties配置，并没在意如下pattern有什么问题。

log4j.appender.A4.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss,sss} [%5p] [%t] [%c:%L] %m%n

------------------------------ 分割线 ------------------------------

我们另一个项目用的日志框架是logback，我们再去验证一下那个项目里记日志有没有这个现象。

经简单验证，logback没有这个现象。

------------------------------ 分割线 ------------------------------

后来，我同事百度了一下，网上有用SSS的。就改为SSS试试。
简单写了个main方法，一跑才发现，果然，正常了。顿时兴奋难以言表。

------------------------------ 分割线 ------------------------------

那么，sss与SSS有什么区别呢？
根据经验，我们马上得到结论，s代表的是秒，比如5/55；ss代表的是两位的秒，比如05/55；sss代表什么，就是3位的秒呗！有3位的秒吗？当然没有了！那是什么呢？那是在两位的秒前面又补了个0，比如005、055。
这时候，再看上面的log截图，就不难理解了。原来诸如2020-12-16 17:28:52,052 2020-12-16 17:28:55,055里面的毫秒是假的，是0+ss。
醍醐灌顶！再一次证明，没有奇怪的问题，没有百思不得解的问题。如果有，只能是自己没有百思，>>百思得解。

话说回来，最初在log4j.properties写出来%d{yyyy-MM-dd HH:mm:ss,sss}这个格式的同学，就应该拉出来突突5分钟。他的一个手误，害得我们纠结这么久。————不过，也未必呀，也许他也不清楚sss与SSS的区别（捂脸笑）。

来源：https://www.cnblogs.com/buguge/p/14145630.html