最简单高效的tryLock

如果任何线程使用都遵守tryLock返回true后再去unlock，不会有线程安全问题的，compareAndSet是个原子操作

正解，只有符合锁占用的时间与获取锁的时间可比拟时，这个类才有意义，所以我列出了适用场景。

你要看情况，
建议楼主看一下为什么要引入偏向锁，就是为了解决CAS延迟问题。http://blogs.sun.com/dave/entry/biased_locking_in_hotspot

你所说的场景不过是你-client的设置罢了，多核CPU再来试试。

看了一下你的链接，谢谢你的提醒，确实有延迟的问题，如果这么考虑，是否CAS都不可靠了呢？这些个原子类什么时候适用？

性能应该只与线程执有锁的时间和多少个线程竞争该锁有关，，为什么会和线程如何得到锁有关？？？

你用tryLock，应该是自旋锁这一类的吧，在我的单核的CPU上，恐怕也不会有什么性能的提高。。。

性能应该只与线程执有锁的时间和多少个线程竞争该锁有关，，为什么会和线程如何得到锁有关？？？

你用tryLock，应该是自旋锁这一类的吧，在我的单核的CPU上，恐怕也不会有什么性能的提高。。。

if(l.tryLock()) {
  try{

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

  } finally {
    l.unlock
  }

}

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

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

我在我电脑上做了一个测试，两者差别没有楼主说的那么大，前者之比后者提高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

我在我电脑上做了一个测试，两者差别没有楼主说的那么大，前者之比后者提高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