最简单高效的tryLock

我在我电脑上做了一个测试，两者差别没有楼主说的那么大，前者之比后者提高10%左右，我看了下JDK1.6的API源码
前者调用方法：
public final boolean compareAndSet(boolean expect, boolean update) {
        int e = expect ? 1 : 0;
        int u = update ? 1 : 0;
        return unsafe.compareAndSwapInt(this, valueOffset, e, u);
    }

后者调用方法：
final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }

protected final boolean compareAndSetState(int expect, int update) {
        // See below for intrinsics setup to support this
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
    }

两者的源码并没有本质区别呀，所以为什么会有lz描述的那种情况，而我测试也没有这种情况，我CPU 双核，Windows

我在公司里的开发环境（XP,双核）上测试确实是10%左右，但在CentOS X86_64 5.4 4核的服务器上跑上面的那个测试程序，大概相差2倍多，在家里的笔记本上xp, 单核的大概也是2倍多，刚才我也翻了下JDK1.6的代码，发现确实没有什么本质区别，我想原因可能在于我的测试程序（第一页里）和我的应用环境(加锁，判断，如果符合条件修改一个标志位，然后解锁)中从获取锁到释放锁的操作非常快以至于tryLock本身的操作所占的比重比较大。至于双核的XP上为什么只有10%，没想明白

if(l.tryLock()) {
  try{

   // 这里能有多个线程同时到达？

  } finally {
    l.unlock
  }

}

在你的代码中，那个逻辑判断是可靠的，但是中间的执行代码是线程不安全的。

PS:CAS是可靠的，它是Wait-free的实现，不过它只能针对单个资源安全，不能作为多语句的原子操作。

我自己测下来用synchronized关键字更快，我想应该是这种spin lock有很多cas操作都是无效的，cas本身也是代价很大的。