Waits at most millis milliseconds for this thread to die. A timeout of 0 means to wait forever. This implementation uses a loop of this.wait calls conditioned on this.isAlive. As a thread terminates the this.notifyAll method is invoked. It is recommended that applications not use wait, notify, or notifyAll on Thread instances
Java对象有包含两个Word的头部。其中,第一个word被称为mark word,用来包含和垃圾收集、hash码的一些信息。第二个word用来指向对象的类。
第一个word的解释比较复杂,它包含两个bit用于指明mark word的用途。
01:
10: 表明这个对象被锁住,并且有冲突发生,因而正在被复杂而低效的操作系统同步机制保护。剩余的bit是一个指向monitor的指针。
接下来,我们要谈谈对锁的优化。从文章《HotSpot: A new breed of virtual machine 》中,我们可以看到早期的JVM花在线程同步上的开销是惊人的,线程同步的开销占到了执行时间的21%。而且这个开销不能简单的被JIT优化掉。因此,众多牛人提出了对锁的很多优化。
目前,JDK中最新的Biased锁是基于下面的观察:
void lock(Object obj, Thread currentTr){ if( obj biased to currentTr) return; if( obj biased to other thread) pause owner thread at safe point change mark word and lock record to pretend that obj is locked by other thread with general lock. else{ //fall to common lock } } void unlock(Object obj, Thread currentTr){ if( obj biased to currentTr) return . else fall to common lock }
简单来说在JVM中monitorenter和monitorexit字节码依赖于底层的操作系统的Mutex Lock来实现的,但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行,这种切换的代价是非常昂贵的;然而在现实中的大部分情况下,同步方法是运行在单线程环境(无锁竞争环境)如果每次都调用Mutex Lock那么将严重的影响程序的性能。不过在jdk1.6中对锁的实现引入了大量的优化,如锁粗化(Lock Coarsening)、锁消除(Lock Elimination)、轻量级锁(Lightweight Locking)、偏向锁(Biased Locking)、适应性自旋(Adaptive Spinning)等技术来减少锁操作的开销。
简单讲一下这个类。Java无法直接访问底层操作系统,而是通过本地(native)方法来访问。不过尽管如此,JVM还是开了一个后门,JDK中有一个类Unsafe,它提供了硬件级别的原子操作。
这个类尽管里面的方法都是public的,但是开发者是无法使用它的,JDK API文档也没有提供关于这个类的方法解析。对于Unsafe类的使用都是受限制的,只有授信的代码才能获得该类的实例,当然JDK库里面的类是可以随意使用的。
从第一行的描述可以了解到Unsafe提供了硬件级别的操作,比如说获取某个属性在内存中的位置,比如说修改对象的字段值,即使它是私有的。不过Java本身就是为了屏蔽底层的差异,对于一般的开发而言也很少会有这样的需求。
例如下面的方法,分别用来分配内存,扩充内存和释放内存的:
public native long allocateMemory(long paramLong); public native long reallocateMemory(long paramLong1, long paramLong2); public native void freeMemory(long paramLong);
CAS,Compare and Swap即比较并替换,设计并发算法时常用到的一种技术,java.util.concurrent包全完建立在CAS之上,没有CAS也就没有此包,可见CAS的重要性。
当前的处理器基本都支持CAS,只不过不同的厂家的实现不一样罢了。CAS有三个操作数:内存值V、旧的预期值A、要修改的值B,当且仅当预期值A和内存值V相同时,将内存值修改为B并返回true,否则什么都不做并返回false。
CAS也是通过Unsafe实现的,看下Unsafe下的三个方法:
public final native boolean compareAndSwapObject(Object paramObject1, long paramLong, Object paramObject2, Object paramObject3); public final native boolean compareAndSwapInt(Object paramObject, long paramLong, int paramInt1, int paramInt2); public final native boolean compareAndSwapLong(Object paramObject, long paramLong1, long paramLong2, long paramLong3);
下面是 AtomicInteger 中 addAndGet()
方法的定义:
public final int addAndGet(int delta) { for (;;) { int current = get(); int next = current + delta; if (compareAndSet(current, next)) return next; } }
这段代码如何在不加锁的情况下通过CAS实现线程安全,我们不妨考虑一下方法的执行:
整个过程中,利用CAS保证了对于value的修改的线程安全性
CAS看起来很美,但这种操作显然无法涵盖并发下的所有场景,并且CAS从语义上来说也不是完美的,存在这样一个逻辑漏洞:如果一个变量V初次读取的时候是A值,并且在准备赋值的时候检查到它仍然是A值,那我们就能说明它的值没有被其他线程修改过了吗?如果在这段期间它的值曾经被改成了B,然后又改回A,那CAS操作就会误认为它从来没有被修改过。这个漏洞称为CAS操作的"ABA"问题。java.util.concurrent包为了解决这个问题,提供了一个带有标记的原子引用类"AtomicStampedReference",它可以通过控制变量值的版本来保证CAS的正确性。不过目前来说这个类比较"鸡肋",大部分情况下ABA问题并不会影响程序并发的正确性,如果需要解决ABA问题,使用传统的互斥同步可能回避原子类更加高效。
参考文章 Unsafe 与 CAS