Tomcat had this same issue a while back. It was trying to use a single SimpleDateFormat object to parse/format date-valued HTTP headers. I submitted the patch for it and I think we decided to just instantiate as needed. Local variables are garbage collected much more reliably from what I understand. And, as Simon pointed out, the probable disk i/o would be the big bottleneck, not the object instantiation.
> You could just take a private copy of FastDateFormat from commons-lang > which is thread-safe. Might bloat your jar-file size though. > Stephen > > 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > James Carman, President Carman Consulting, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
