commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: Logging: SimpleLog not thread-safe
Date Sat, 14 Oct 2006 09:32:28 GMT
You could just take a private copy of FastDateFormat from commons-lang 
which is thread-safe. Might bloat your jar-file size though.

Simon Kitching wrote:
> HI,
> On Fri, 2006-10-13 at 00:10 -0400, Kenneth Xu wrote:
>>Yes, it'll be GC'ed when thread is. And initialized when first use in a new
>>thread. Here is the test code:
> But if an application has long-running threads then the object won't be
> recycled until the thread dies. So an app with 100 threads has 100
> SimpleDateFormat objects long-term. 
> And as James noted, when using frameworks like Application Servers,
> threads could be pooled in unexpected ways.
> I also suspect that in order to fetch data from a ThreadLocal, the JVM
> effectively performs a get on a synchronised map, ie that ThreadLocal is
> not much more efficient than having a synchronised static DateFormat on
> SimpleLog (nb: I have no proof of this, just a hunch).
> I think the easiest & most reliable solution is to simply create a
> SimpleDateFormat object in the method that needs it. Note that this is
> only done after it has been determined that a message *will* be output,
> which in most cases means that there will be disk io that will have far
> more impact on the system than creating a simple object. Optimising the
> path in commons-logging that determines *if* a message is to be logged
> is important; optimising the actual logging operation is much less
> critical.
> Of course I'm open to persuasion on this (eg performance stats)..
> Cheers,
> Simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message