同步是一种很必要的机制用来控制对共享数据的访问。尤其在用户很多的情况时，例如：像web应用这样，相同的代码可以同时被多个线程执行，取保数据访问被保护是十分重要的。无论是Java或.NET，在使用锁或同步时都提供了相同的性能指标。这里有一些文章值得一读：
- .NET 2.0 Performance Guidelines – Locking and Synchronization
- Thread Synchronization and the Java Monitor
一个识别同步问题的简单方法
我试图找到一种简单的方法来识别多线程中执行的代码中的同步问题。在我的应用中，我有几个方法和组件同步访问共享数据。代码是作为Web应用的一部分来执行的。越多的用户同时访问页面，独立的线程访问同步块所需的时间可能会更长。对于我来说，问题在于：
- 我的哪个方法由于同步原因而影响到了整个系统的性能？
- 影响性能到什么程度？
- 我的应用中还有其他的代码存在相同的问题么？
回答上述问题的一个方法，尽管不是百分之百准确，但是很容易执行。我只是取得某一方法、组件或框架的CUP时间和方法执行的时间。下面我对这两个参数做下解释：
- CPU时间：代码执行所需花费的CPU时间。
- 执行时间：是方法执行所花费的总的时间。包括花费在CPU、I/O、等待其他系统响应、垃圾回收所花费的时间和进入同步的代码块所等待的时间。
我增加Web应用的负载并把这些值做成表格。我把CPU时间和它的运行时间做比较。对这两种值的比较显示出了等待I/O、其他系统或等待进入同步的代码块所需的时间。因为这个差值不只包含同步时间，所以如同我上面所说，这个方法不是百分之百准确。尽管不是100%准确，但是它给你指出了你的代码哪处需要等待。如果你刚好知道你的代码不需要外部数据库调用或不做任何I/O操作，就差不多能确保这就是同步花费的时间。
我的例子
我使用dynaTrace 来订阅我要分析方法的执行时间和CPU时间。然后我用一个负载测试工具对我的Web应用做模拟负载测试，点击执行有问题代码的页面。在我的测试场景中，我使用SilkPerformer 显示如下：
从这些结果中我抓取了一些方法层的结果。下面的图片显示CPU时间（绿色）只是有些细微的增长，但执行的时间和我的页面的总体响应时间保持同样的增长。注意下图对CPU时间和执行时间用了不同刻度比例，让他们差异更显而易见。
下面的图片是对这两个数值采用相同刻度比例的图片：
测试结果的解释
事实上我的方法执行的总时间增加的非常迅速，但CPU时间几乎没有变，这说明我的方法在可能在等待I/O、其他系统或同步代码块上花费了很重要的时间。
从方法扩展到组件或框架来分析
如果你的工具可以抓取一个完整组件或一个框架库的CPU时间和执行时间，这个方法同样可用。下面的图片是对.NET远程组件抓取的时间.
结论
这是一个你能够用来识别你哪处代码花费了大部分时间等待同步或其他系统响应。
本文摘自：
翻译的不好，见谅！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
