标签：multi-thread

    以下为转http://www.thedwick.com/blog/2008/04/simpledateformat-performance-pig/的一篇关于simpleDateformat中使用的一些误区以及怎么样来安全有效地使用simpleDateFormat。在本文中，描述了创造simpleDateFormat的昂贵代价，以及使用静态实例的多线程错误以及同步时的低效问题，并提出一个提升的解决办法。
    全文如下：

    Just yesterday I came across this problem “in the wild” for the third time in my career so far: an application with performance problems creating tons of java.text.SimpleDateFormat instances. So, I have to get this out there: creating a new instance of SimpleDateFormat is incredibly expensive and should be minimized. In the case that prompted this post, I was using JProfiler to profile this code that parses a CSV file and discovered that 50% of the time it took to suck in the file and make 55,000 objects out of it was spent solely in the constructor of SimpleDateFormat. It created and then threw away a new one every time it had to parse a date. Whew!

  “Great,” you think, “I’ll just create one, static instance, slap it in a field in a DateUtils helper class and life will be good.”
    Well, more precisely, life will be good about 97% of the time. A few days after you roll that code into production you’ll discover the second cool fact that’s good to know: SimpleDateFormat is not thread safe. Your code will work just fine most of the time and all of your regression tests will probably pass, but once your system gets under a production load you’ll see the occasional exception.
    “Fine,” you think, “I’ll just slap a ‘synchronized’ around my use of that one, static instance.”
    Ok, fine, you could do that and you’d be more or less ok, but the problem is that you’ve now taken a very common operation (date formatting and parsing) and crammed all of your otherwise-lovely, super-parallel application through a single pipe to get it done.
    What would be better is to use a ThreadLocal variable so you can have your cake and eat it, too:

继续阅读“安全有效地提升simpleDateFormat性能”