java - Synchronizing on SimpleDateFormat vs. clone -

we know dateformat classes not thread safe. have multi-threaded scenario dateformats needs used. can't create new instance in new thread simpledateformat creation seems expensive(the constructor ends calling "compile" costly). after tests 2 options left me are:

1. external synchronization - dont want this
2. cloning in each thread - don't know whether there catches?

any suggestions?

if guys have faced before, direction did take.

note: similar question asked before, closed pointing apache package. can't use new libraries this. , have read similar question on so

what if created class format dates using fixed size pool of precreated simpledateformat objects in round-robin fashion? given uncontested synchronization cheap, synchronize on simpledateformat object, amortizing collisions across total set.

so there might 50 formatters, each used in turn - collision, , therefore lock contention, occur if 51 dates formatted simultaneously.

edit 2011-02-19 (pst)

i implemented fixed pool suggested above, code (including test), available on website.

following results on quad core amd phenom ii 965 be, running in java 6 se client jvm:

2011-02-19 15:28:13.039 : threads=10, iterations=1,000,000 2011-02-19 15:28:13.039 : test 1: 2011-02-19 15:28:25.450 :   sync      : 12,411 ms 2011-02-19 15:28:37.380 :   create    : 10,862 ms 2011-02-19 15:28:42.673 :   clone     : 4,221 ms 2011-02-19 15:28:47.842 :   pool      : 4,097 ms 2011-02-19 15:28:48.915 : test 2: 2011-02-19 15:29:00.099 :   sync      : 11,184 ms 2011-02-19 15:29:11.685 :   create    : 10,536 ms 2011-02-19 15:29:16.930 :   clone     : 4,184 ms 2011-02-19 15:29:21.970 :   pool      : 3,969 ms 2011-02-19 15:29:23.038 : test 3: 2011-02-19 15:29:33.915 :   sync      : 10,877 ms 2011-02-19 15:29:45.180 :   create    : 10,195 ms 2011-02-19 15:29:50.320 :   clone     : 4,067 ms 2011-02-19 15:29:55.403 :   pool      : 4,013 ms 

notably, cloning , pooling close together. in repeated runs, cloning faster pooling slower. test, of course, deliberately designed extreme contention.

in specific case of simpledateformat, think might tempted create template , clone on demand. in more general case, might tempted use pool such things.

before making final decision 1 way or other, want thoroughly test on variety of jvms, versions , variety of these kinds of objects. older jvms, , on small devices handhelds , phones might have more overhead in object creation , garbage collection. conversely, might have more overhead in uncontested synchronization.

fwiw, review of code, seemed simpledateformat have work in being cloned.

edit 2011-02-19 (pst)

also interesting uncontended single-threaded results. in case pool performs on par single synchronized object. imply pool best alternative overall, since delivers excellent performance when contented , when uncontended. little surprising cloning less when single threaded.

2011-02-20 13:26:58.169 : threads=1, iterations=10,000,000 2011-02-20 13:26:58.169 : test 1: 2011-02-20 13:27:07.193 :   sync      : 9,024 ms 2011-02-20 13:27:40.320 :   create    : 32,060 ms 2011-02-20 13:27:53.777 :   clone     : 12,388 ms 2011-02-20 13:28:02.286 :   pool      : 7,440 ms 2011-02-20 13:28:03.354 : test 2: 2011-02-20 13:28:10.777 :   sync      : 7,423 ms 2011-02-20 13:28:43.774 :   create    : 31,931 ms 2011-02-20 13:28:57.244 :   clone     : 12,400 ms 2011-02-20 13:29:05.734 :   pool      : 7,417 ms 2011-02-20 13:29:06.802 : test 3: 2011-02-20 13:29:14.233 :   sync      : 7,431 ms 2011-02-20 13:29:47.117 :   create    : 31,816 ms 2011-02-20 13:30:00.567 :   clone     : 12,382 ms 2011-02-20 13:30:09.079 :   pool      : 7,444 ms