Java练级打怪路----synchronized对比cas

前言

这篇文章的营养非常有限，只是一个夜黑风高的晚上，突发奇想，如果我要统计一个网站的PV，程序应该怎么写呢？

一种挫逼的写法

这是一种无锁的写法，很明显，这个东西是线程不安全的。我们使用12个线程，每个线程执行 10 ^{8次方add的操作，发现最终的结果并没有得到期望的1.2*10}9次方。

上面一个是总数，下面一个是所消耗的时间。

synchronized VS cas

很明显，我们需要一个锁来干这个事情。

synchronized

synchronized关键字，是Java中一个同步锁，主要有一下几种用法：

• 修饰一个代码块，被修饰的代码块称为同步语句块，其作用的范围是大括号{}括起来的代码
• 修饰一个方法，被修饰的方法称为同步方法，其作用的范围是整个方法
• 修饰一个静态的方法，其作用的范围是整个静态方法。

cas

compareAndSet，如果之前了解过C语言或者操作系统，相信对cas不会太陌生，这是一个原子方法。Java中我们可以使用sun.misc.Unsafe#compareAndSwapLong这个方法。

对比

• 测试环境：

• 测试条件：
  每个线程执行1千万次add 1操作
• 测试结果：（4次取平均值）

线程数	synchronized耗时(ms)	cas耗时(ms)	方法三(ms)
1	296	142	92
4	2749	2611	999
8	5797	4845	1851
16	11223	10192	3702
32	14949	20009	7779
64	31415	39974	13784

发现

• synchronized好快
  我们发现synchronized关键一开始落后于cas，但是在后期却完成反超。synchronized其实在JDK1.5进行一波更新。速度大大的提升。
  后面我们再继续深入将jdk对synchronized的优化。
  cas在竞争激烈的时候速度反而下降。不难想象反复的失败重试。

• CPU资源问题
  我们发现了一个事情，synchronized执行的过程中，CPU的资源一直上不去，这个也不难想到原因，因为其他线程一直竞争不到锁，一直处于阻塞的状态。

  
  
  
  
  

  cas模型的CPU基本打满。

  
  
  

• cas的优化
  jdk为我们提供了一个类java.util.concurrent.atomic.AtomicLong，效果可以显著提高。方法三我就是用这个测出来的。虽然方法二的实现跟方法三的一模一样，我最后都直接copy代码出来了，但仍然达不到该效率，估计是有jvm级别的优化。
  当然我们可以模拟jvm对synchronized的优化，简单的说，jvm的moniter会根据竞争的情况而调整synchronize的锁，我们按照这一思路，如果cas交换次数失败到一定的次数，就阻塞这个线程。

  
  
  
  
  

  增加了这个条件之后耗时大概减少了40%，CPU的使用降低70%（32线程/64线程条件下）,当然这个1000是我胡乱搞出来的一个值，但线程数提升上去后仍然比synchronized慢。

• synchronized是个好东西
  synchronized是一个非常稳定的东西，虽然效率不一定是最佳的。但确实非常好用，下面再来认真研究研究。