Yes, it'll be GC'ed when thread is. And initialized when first use in a new
thread. Here is the test code:
public class TestMe {
private static String pattern = "yyyy-mm-dd";
private static ThreadLocal formatter = new ThreadLocal() {
protected Object initialValue() {
return new SimpleDateFormat(pattern);
}
};
public static void main(String[] args) throws Exception{
test2();
}
public static void test2() {
Date date = new Date();
int size=1000000;
long l;
l = System.currentTimeMillis();
for (int i=0; i<size; i++) {
((DateFormat)formatter.get()).format(date);
}
System.out.println(System.currentTimeMillis()-l);
l = System.currentTimeMillis();
for (int i=0; i<size; i++) {
(new SimpleDateFormat(pattern)).format(date);
}
System.out.println(System.currentTimeMillis()-l);
}
}
-----Original Message-----
From: James Carman [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 12, 2006 10:26 AM
To: 'Jakarta Commons Developers List'
Subject: RE: Logging: SimpleLog not thread-safe
I guess it will clean itself up when the thread is garbage collected. I'd
play around with it just to be sure, though. Application servers typically
use a thread pool, so they won't be garbage collected. But, that's okay,
because you want to be able to reuse them if you can to avoid having to
reconstruct it from scratch.
-----Original Message-----
From: James Carman [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 12, 2006 6:23 AM
To: Jakarta Commons Developers List
Subject: RE: Logging: SimpleLog not thread-safe
How do you know when to clean it up? Just instantiate a new one each time.
> It might do; not sure what the performance of ThreadLocal is. However
> the price is extra memory usage: a DateFormatter for every thread in the
> system that ever logs a message.
>
> On Wed, 2006-10-11 at 17:42 -0400, Kenneth Xu wrote:
>> Hi,
>>
>> I think a thread local formatter will give us better performance than
>> creating one new in every log invocation.
>>
>> Just my 2 cents,
>>
>> Thanks,
>> Ken
>>
>> -----Original Message-----
>> From: Simon Kitching [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, October 11, 2006 5:05 AM
>> To: Jakarta Commons Developers List
>> Subject: Re: Logging: SimpleLog not thread-safe
>>
>> Hi Martin,
>>
>> Thanks very much for letting us know about this. I think you're right
>> about there being a thread-safety issue.
>>
>> SimpleLog is definitely in use, but obviously this bug will only be
>> triggered under pretty rare conditions, and I expect would usually just
>> result in a malformed date string which may not be noticed anyway.
>>
>> But it should be fixed; I'll try to do that this weekend.
>>
>> Regards,
>>
>> Simon
>>
>> On Fri, 2006-10-06 at 17:15 +0100, Martin Wilson wrote:
>> > Hi,
>> >
>> > I'm not sure if anyone else uses the SimpleLog class - anyway I've
>> > noticed that SimpleLog.log is not thread-safe. The following code
>> > (starting on line 282):
>> >
>> > if(showDateTime) {
>> > buf.append(dateFormatter.format(new Date()));
>> > buf.append(" ");
>> > }
>> >
>> > makes an unsynchronized call to dateFormatter.format. As dateFormatter
>> > is an instance variable, and DateFormat.format is not thread-safe,
>> this
>> > will cause problems if more than one thread tried to log at the same
>> > time.
>> >
>> > Solution: remove the dateFormatter instance variable and instantiate a
>> > new DateFormat each time in the log method, e.g.
>> >
>> > DateFormat dateFormatter = null;
>> > try {
>> > dateFormatter = new
>> > SimpleDateFormat(dateTimeFormat);
>> > }
>> > catch(IllegalArgumentException e) {
>> > dateFormatter = new
>> > SimpleDateFormat(DEFAULT_DATE_TIME_FORMAT);
>> > }
>> >
>> > Is anyone available who could make this change?
>> >
>> > Thanks,
>> > Martin
>>
>> > ___________
>> >
>> > Martin Wilson
>> > [EMAIL PROTECTED]
>> >
>> > Bright Interactive: successfully delivering interactive websites and
>> > business applications
>> > <http://www.bright-interactive.com/>
>> http://www.bright-interactive.com
>> > 0870 240 6520
>> >
>>
>>
>> ---------------------------------------------------------------------
>> 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]
>>
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
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]
