前言
这篇文章的营养非常有限，只是一个夜黑风高的晚上，突发奇想，如果我要统计一个网站的PV，程序应该怎么写呢？
一种挫逼的写法
这是一种无锁的写法，很明显，这个东西是线程不安全的。我们使用12个线程，每个线程执行 108次方add的操作，发现最终的结果并没有得到期望的1.2*109次方。
上面一个是总数，下面一个是所消耗的时间。
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是一个非常稳定的东西，虽然效率不一定是最佳的。但确实非常好用，下面再来认真研究研究。
