在SimpleDateFormat和克隆上同步 [英] Synchronizing on SimpleDateFormat vs. clone
问题描述
我们知道 dateformat 类不是线程安全的。我有一个多线程场景，需要使用dateformats。我无法在新线程中创建新实例，因为 SimpledateFormat 创建似乎很昂贵（构造函数最终调用编译，这是昂贵的）。经过一些测试后，我只剩下两个选项：
We know that the dateformat classes are not thread safe. I have a multi-threaded scenario where dateformats needs to be used. I can't really create a new instance in new thread as SimpledateFormat creation seems to be expensive(the constructor ends up calling "compile" which is costly). After some tests the only two options left for me are:
- 外部同步 - 我真的不想这样做
- 在每个帖子中克隆 - 不知道是否有一些捕获？
有任何建议吗？
如果之前有人面对这个问题，你采取了什么方向。
If guys have faced this before, what direction did you take.
注意：a < a href =http://www.javakb.com/Uwe/Forum.aspx/java-programmer/3943/Synchronizing-on-SimpleDateFormat-vs-clone =nofollow noreferrer>类似的问题是之前问过，但它被关闭指向一个apache包。我不能为此使用新库。
我也读过类似的关于SO的问题
Note: a similar question was asked before, but it was closed pointing to a apache package. I can't use new libraries for this. And I have also read this similar question on SO
推荐答案
如果你创建了一个类，它会以循环方式使用固定大小的预创建的SimpleDateFormat对象格式化日期？鉴于无争议的同步很便宜，这可以在SimpleDateFormat对象上同步，在整个集合中分摊冲突。
What if you created a class which would format dates using a fixed size pool of precreated SimpleDateFormat objects in round-robin fashion? Given that uncontested synchronization is cheap, this could synchronize on the SimpleDateFormat object, amortizing collisions across the total set.
因此可能有50个格式化程序，每个都依次使用 - 碰撞，因此锁定争用只有在51个日期实际同时格式化时才会发生。
So there might be 50 formatters, each used in turn - collision, and therefore lock contention, would occur only if 51 dates were actually formatted simultaneously.
编辑2011-02-19（太平洋标准时间）
我按照上面的建议实现了一个固定池，其代码（包括测试）是可在我的网站上找到。
I implemented a fixed pool as suggested above, the code for which (including the test), is available on my website.
以下是四核AMD Phenom II 965 BE的运行结果，正在运行在Java 6 SE客户端JVM中：
Following are the results on a Quad Core AMD Phenom II 965 BE, running in the 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 and pooling were very close together. In repeated runs, cloning was faster than pooling about as often as it was slower. The test, of course, was deliberately designed for extreme contention.
在SimpleDateFormat的特定情况下，我想我可能只想创建一个模板并克隆它一经请求。在更一般的情况下，我可能会想要使用这个池来做这些事情。
In the specific case of the SimpleDateFormat, I think I might be tempted to just create a template and clone it on demand. In the more general case, I might be tempted to use this pool for such things.
在做出最终决定之前，我想彻底测试一下在各种JVM，版本和各种这些对象上。较旧的JVM以及手持设备和手机等小型设备上的JVM可能会在对象创建和垃圾收集方面产生更多开销。相反，他们可能在无争议的同步中有更多的开销。
Before making a final decision one way or the other, I would want to thoroughly test on a variety of JVMs, versions and for a variety of these kinds of objects. Older JVMs, and those on small devices like handhelds and phones might have much more overhead in object creation and garbage collection. Conversely, they might have more overhead in uncontested synchronization.
FWIW，从我对代码的评论来看，似乎SimpleDateFormat最有可能做的工作就是克隆。
FWIW, from my review of the code, it seemed that SimpleDateFormat would most likely have the most work to do in being cloned.
编辑2011-02-19（太平洋标准时间）
同样有趣是无争用的单线程结果。在这种情况下，池与单个同步对象相同。这意味着该池是整体上最好的替代方案，因为它在满足和无条件时提供了出色的性能。有点令人惊讶的是单线程克隆效果不佳。
Also interesting are the uncontended single-threaded results. In this case the pool performs on par with a single synchronized object. This would imply that the pool is the best alternative overall, since it delivers excellent performance when contented and when uncontended. A little surprising is that cloning is less good 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
这篇关于在SimpleDateFormat和克隆上同步的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
