我已经阅读了几个问题，并且通过文档似乎唯一的区别是性能。
比较RollingFile和RollingRandomAccessFile的相关问题 .
在这个问题中，答案谈到了unix logrotate utility但我不确定这是否与我的问题有关。
来自 Apache 文档：
"RollingRandomAccessFileAppender类似于标准的RollingFileAppender，除了它总是缓冲的(这不能被关闭(，并且在内部它使用ByteBuffer + RandomAccessFile而不是BufferedOutputStream。与 RollingFileAppender 相比，我们看到性能提高了 20-200%...">
是否有任何重大理由不使错误日志处理成为RollingRandomAccessFile而不是类似的东西：
<RollingFile name="error" atr="atrib-val" >
<PatternLayout>
<Pattern>%d{date}</Pattern>
</PatternLayout>
</RollingFile>
错误处理是否需要与正常日志的Appender不同？错误日志不需要常量缓冲区吗？
log4j关于异步记录器的页面解释了权衡：
Benefits:
- Higher peak throughput. With an asynchronous logger your application can log messages at 6 - 68 times the rate of a synchronous logger.
This is especially interesting for applications that occasionally need to log bursts of messages. Async logging can help prevent or dampen latency spikes by shortening the wait time until the next message can be logged. If the queue size is configured large enough to handle the burst, asynchronous logging will help prevent your application from falling behind (as much) during a sudden increase of activity.
- Lower logging response time latency. Response time latency is the time it takes for a call to Logger.log to return under a given workload. Asynchronous Loggers have consistently lower latency than synchronous loggers or even queue-based asynchronous appenders.
Drawbacks:
- Error handling. If a problem happens during the logging process and an exception is thrown, it is less easy for an asynchronous logger or appender to signal this problem to the application. This can partly be alleviated by configuring an ExceptionHandler, but this may still not cover all cases. For this reason, if logging is part of your business logic, for example if you are using Log4j as an audit logging framework, we would recommend to synchronously log those audit messages. (Note that you can still combine them and use asynchronous logging for debug/trace logging in addition to synchronous logging for the audit trail.)
- In some rare cases, care must be taken with mutable messages. Most of the time you don't need to worry about this. Log4 will ensure that log messages like logger.debug("My object is {}", myObject) will use the state of the myObject parameter at the time of the call to logger.debug(). The log message will not change even if myObject is modified later. It is safe to asynchronously log mutable objects because most Message implementations built-in to Log4j take a snapshot of the parameters. There are some exceptions however: MapMessage and StructuredDataMessage are mutable by design: fields can be added to these messages after the message object was created. These messages should not be modified after they are logged with asynchronous loggers or asynchronous appenders; you may or may not see the modifications in the resulting log output. Similarly, custom Message implementations should be designed with asynchronous use in mind, and either take a snapshot of their parameters at construction time, or document their thread-safety characteristics.
- If your application is running in an environment where CPU resources are scarce, like a machine with one CPU with a single core, starting another thread is not likely to give better performance.
- If the sustained rate at which your application is logging messages is faster than the maximum sustained throughput of the underlying appender, the queue will fill up and the application will end up logging at the speed of the slowest appender. If this happens, consider selecting a faster appender, or logging less. If neither of these is an option, you may get better throughput and fewer latency spikes by logging synchronously.