logback中默认情况下不应该在什么时候使用AsyncAppender？

Question

Logback支持使用ch.qos.Logback.classic.AsyncAppender类来实现异步日志记录，根据文档说明，这将减少应用程序的日志处理开销。那么，为什么不将其作为默认设置呢？在什么情况下使用同步appender更好？我能看到Async appender的一个问题是日志信息不会按照时间顺序排列。是否存在其他类似的限制？

- Tapan Chandra

Answer 1

AsyncAppender是分派日志事件到其他appender的缓存器，它可以将日志事件缓冲并分派到FileAppender、ConsoleAppender等输出源。

• 为什么要使用AsyncAppender？

  • AsyncAppender可以缓冲日志事件，使应用程序代码可以继续执行而不必等待记录子系统完成写入操作。在底层appender响应缓慢的情况下可以提高应用程序的响应性能，例如：数据库或文件系统容易发生争用的情况。

• 为什么不能把它作为默认行为？

  • AsyncAppender无法直接写入文件、控制台、数据库或套接字等，而是将日志事件委托给可以执行此功能的appender。没有底层appender，AsyncAppender实际上是一个无操作。
  • 日志事件缓冲区位于应用程序堆上，可能会造成资源泄漏。如果缓冲区建立得比可以处理的速度快，那么缓冲区将占用应用程序可能需要的资源。
  • AsyncAppender需要配置来平衡不丢失和资源泄漏之间的竞争需求，并处理其缓冲区在关闭时的排出，这意味着它比使用同步写入更复杂。因此，基于简单性原则，Logback默认的写入策略是同步。

AsyncAppender公开了配置杠杆，可用于解决潜在的资源泄漏问题，例如：

• 可以增加缓冲容量
• 可以指示Logback在缓冲区达到最大容量时丢弃事件
• 您可以控制要丢弃哪种类型的事件；例如在ERROR事件之前丢弃TRACE事件等

AsyncAppender还公开了配置杠杆，您可以使用它们来限制（但不能消除）应用程序关闭期间事件的丢失。

然而，最简单且最安全的确保日志事件成功写入的方法仍然是同步写入。只有在已经证明写入到appender实质性地影响应用程序的响应/吞吐量时，才应考虑使用 AsyncAppender。

- glytching

---

谢谢。这也纠正了我的错误假设，即异步记录器可能会以与记录不同的顺序分派日志消息。由于消息被缓冲和刷新，因此在时间上不应有任何丢失。 - Tapan Chandra