PatternLayout（log4j）的C，F，L，l和M到底有多慢？
众所周知，PatternLayout的C ， F ， L ， l和M 很慢 ：
警告生成调用者位置信息非常慢，应该避免，除非执行速度不是问题。
此外， 本书还提到某些应用程序只能通过更改日志记录格式来获得10％的速度。
但问题是，这些转换字符到底有多慢？
我使用FileAppender在我的计算机上本地测量。 我很好地调试了测试，测量了许多执行并平均了（相对一致的）结果。 循环包含execs++;log.info("t"); 确切的数字并不重要（因为它们取决于我的电脑），但比例确实如此。 我在Java 1.6.0_10（客户端VM）上使用了log4j-1.2.16.jar。
事实certificate，只要模式中出现C, F, L, l or M中的任何一个，记录速度至少慢5倍。
这些标记为慢的主要原因是因为它们表示的信息是通过抛出exception并分析exception的堆栈跟踪来检索的。
设计PatternLayout时，堆栈跟踪生成是一个非常昂贵的过程，所以这是公平的警告。 JVM技术的进步已经在这方面有所改进，因此该过程不再那么昂贵。 尽管今天有更快的方法来获取所需的信息，但据我所知，这些方法由于注意向后兼容早期版本的Java而未被使用。
换句话说，这并不像以前那么糟糕。
假设您不仅在学术上对答案感兴趣，而且担心登录实际应用程序的成本：
我已经在生产应用程序中使用它们并且它们从未提出过问题，主要是因为日志记录是一个相对不常见的事件。 当然，这些应用程序都是I / O绑定的（不是记录所在的磁盘/分区），并且机器有足够的CPU周期（但它们只是PIII-1133机器），但绝大多数都适用（网络）应用程序。 我只是使用它们，直到分析显示您的日志记录是一个瓶颈而不用担心它。