I’ve used it for an in-memory log with a restricted size. For example, the application would write log entries while processing user requests. Whenever an exception occurred (that would be disruptive to the processing) the log records currently in memory would be dumped along with it.
The benefit of a circular buffer is, that you don’t need infinite amounts of memory, since older entries get overridden automatically. The “challange” is, that you need to find a suitable size for your usecase. In the example above, it would be very unfortunate when the log record with the most vital information about the exception would have already been overridden.
Some systems/applications have tools to let you extract the current content of the buffer on demand, and not only when it would be extract automatically (if ever).
I believe ETW and the CLRs stress log, amongst many other system’s kernel or highperformance trace/logging, are implemented that way.
The concept of using such buffers for in-memory tracing/logging is actually pretty common (not to say that this is the only use – certainly not), because it is way faster than written records to a file/database that you might never be interested in unless an error occurs. And on a related note, it conserves harddisk space.