自旋

Java对象保存在内存中时，由以下三部分组成： 对象头 实例数据 对齐填充字节 而对象头又由下面几部分组成： Mark Word 指向类的指针 数组长度（只有数组对象才有） 1. Mark Word Mark Word记录了对象和锁有关的信息，当这个对象被synchronized关键字当成同步锁时，围绕这个锁的一系列操作都和Mark Word有关。Mark Word在32位JVM中的长度是32bit，在64位JVM中长度是64bit。 Mark Word在不同的锁状态下存储的内容不同，在32位JVM中是这么存的： 其中无锁和偏向锁的锁标志位都是01，只是在前面的1bit区分了这是无锁状态还是偏向锁状态。Epoch是指偏向锁的时间戳。 JDK1.6以后的版本在处理同步锁时存在锁升级的概念，JVM对于同步锁的处理是从偏向锁开始的，随着竞争越来越激烈，处理方式从偏向锁升级到轻量级锁，最终升级到重量级锁。 JVM一般是这样使用锁和Mark Word的： step1:当没有被当成锁时，这就是一个普通的对象，Mark Word记录对象的HashCode，锁标志位是01，是否偏向锁那一位是0。 step2:当对象被当做同步锁并有一个线程A抢到了锁时，锁标志位还是01，但是否偏向锁那一位改成1，前23bit记录抢到锁的线程id，表示进入偏向锁状态。 step3:当线程A再次试图来获得锁时

前言 我的上一篇博客的案例中，请求锁的线程如果发现锁已经被其他线程占用，它是通过自旋的方式来等待的，也就是不断地尝试直到成功。本篇就讨论一下另一种方式，那就是挂起以等待唤醒。 注：相关代码都来自《Operating System: Three Easy Pieces》这本书。 自旋哪里不好？ 先说明一下，自旋也有它的好处，不过这里先不讲，我们先讲它可能存在哪些问题。 我们考虑一个极端的场景，某个电脑只有一个CPU，这时候有2个线程竞争锁，线程A获得了锁，进入临界区，开始执行临界区的代码（由于只有一个CPU，线程A在执行的时候，线程B只能在就绪队列中等待）。结果线程A还没执行完临界区的代码，时间片就用完了，于是发生上下文切换，线程A被换了出去，现在开始执行线程B，线程B就开始尝试获取锁。 这时候尴尬的事情就来了，拥有锁的线程没在运行，也就不能释放锁。而占据CPU的线程由于获取不到锁，就只能自旋直到用完它的时间片。 这还只是2个线程的情况，如果等待的线程有100多个呢，那在轮询调度器的场景下，线程A是不是要等到这100多个线程全部空转完才能运行，这浪费可就大了！ 用yield()让出CPU怎么样？ yield()方法是把调用线程之间切出，放回就绪队列。这个方法与前面的不同就在于，当线程B恢复执行的时候，它只会尝试一次，如果失败，则直接退出，而不会用完它的整个时间片

数据同步需要依赖锁，那锁的同步又依赖谁？synchronized给出的答案是在软件层面依赖JVM，而Lock给出的方案是在硬件层面依赖特殊的CPU指令，大家可能会进一步追问：JVM底层又是如何实现synchronized的？ 本文所指说的JVM是指Hotspot的6u23版本，下面首先介绍synchronized的实现： synrhronized关键字简洁、清晰、语义明确，因此即使有了Lock接口，使用的还是非常广泛。其应用层的语义是可以把任何一个非null 对象 作为"锁"，当synchronized作用在方法上时，锁住的便是对象实例（this）；当作用在静态方法时锁住的便是对象对应的Class实例，因为 Class数据存在于永久带，因此静态方法锁相当于该类的一个全局锁；当synchronized作用于某一个对象实例时，锁住的便是对应的代码块。在 HotSpot JVM实现中，锁有个专门的名字：对象监视器。 1. 线程状态及状态转换 当多个线程同时请求某个对象监视器时，对象监视器会设置几种状态用来区分请求的线程： Contention List：所有请求锁的线程将被首先放置到该竞争队列 Entry List：Contention List中那些有资格成为候选人的线程被移到Entry List Wait Set：那些调用wait方法被阻塞的线程被放置到Wait Set OnDeck

POSIX threads(简称Pthreads)是在多核平台上进行并行编程的一套常用的API。线程同步(Thread Synchronization)是并行编程中非常重要的通讯手段，其中最典型的应用就是用Pthreads提供的锁机制(lock)来对多个线程之间共 享的临界区(Critical Section)进行保护(另一种常用的同步机制是barrier)。 Pthreads提供了多种锁机制： (1) Mutex（互斥量）：pthread_mutex_*** (2) Spin lock（自旋锁）：pthread_spin_*** (3) Condition Variable（条件变量）：pthread_con_*** (4) Read/Write lock（读写锁）：pthread_rwlock_*** Pthreads提供的Mutex锁操作相关的API主要有： pthread_mutex_lock (pthread_mutex_t *mutex); pthread_mutex_trylock (pthread_mutex_t *mutex); pthread_mutex_unlock (pthread_mutex_t *mutex); Pthreads提供的与Spin Lock锁操作相关的API主要有： pthread_spin_lock (pthread_spinlock_t

转自http://blog.csdn.net/kyokowl/article/details/6294341 POSIX threads(简称Pthreads)是在多核平台上进行并行编程的一套常用的API。线程同步(Thread Synchronization)是并行编程中非常重要的通讯手段，其中最典型的应用就是用Pthreads提供的锁机制(lock)来对多个线程之间共 享的临界区(Critical Section)进行保护(另一种常用的同步机制是barrier)。 Pthreads提供了多种锁机制： (1) Mutex（互斥量）：pthread_mutex_*** (2) Spin lock（自旋锁）：pthread_spin_*** (3) Condition Variable（条件变量）：pthread_con_*** (4) Read/Write lock（读写锁）：pthread_rwlock_*** Pthreads提供的Mutex锁操作相关的API主要有： pthread_mutex_lock (pthread_mutex_t *mutex); pthread_mutex_trylock (pthread_mutex_t *mutex); pthread_mutex_unlock (pthread_mutex_t *mutex); Pthreads提供的与Spin

synchronized 关键字的三种使用方式 　　修饰实例方法，作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁。 　　修饰静态方法，作用于当前类对象加锁，进入同步代码前要获得当前类对象的锁 。也就是给当前类加锁，会作用于类的所有对象实例，因为静态成员不属于任何一个实例对象，是类成员（ static 表明这是该类的一个静态资源，不管new了多少个对象，只有一份，所以对该类的所有对象都加了锁）。所以如果一个线程A调用一个实例对象的非静态 synchronized 方法，而线程B需要调用这个实例对象所属类的静态 synchronized 方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的锁，而访问非静态 synchronized 方法占用的锁是当前实例对象锁。 　　修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象的锁。 和 synchronized 方法一样，synchronized(this)代码块也是锁定当前对象的。synchronized 关键字加到 static 静态方法和 synchronized(class)代码块上都是是给 Class 类上锁。需要注意的是：尽量不要使用 synchronized(String a) 因为JVM中，字符串常量池具有缓冲功能！ synchronized

3 月，跳不动了？>>> 记一次 排它锁 和 自旋锁 的简单实现 定义一个lock接口 public interface PutMessageLock { void lock(); void unlock(); } 排它锁实现 使用java自带的 ReentrantLock 即可 public class PutMessageReentrantLock implements PutMessageLock { private ReentrantLock putMessageNormalLock = new ReentrantLock(); // NonfairSync @Override public void lock() { putMessageNormalLock.lock(); } @Override public void unlock() { putMessageNormalLock.unlock(); } } 自旋锁实现 使用 cas + 循环 来实现 public class PutMessageSpinLock implements PutMessageLock { //true: Can lock, false : in lock. private AtomicBoolean putMessageSpinLock = new AtomicBoolean(true)

3 月，跳不动了？>>> 自旋锁（Spin lock） 自旋锁是指当一个线程尝试获取某个锁时，如果该锁已被其他线程占用，就一直循环检测锁是否被释放，而不是进入线程挂起或睡眠状态。 自旋锁适用于锁保护的临界区很小的情况，临界区很小的话，锁占用的时间就很短。 简单的实现 import java.util.concurrent.atomic.AtomicReference; public class SpinLock { private AtomicReference<Thread> owner = new AtomicReference<Thread>(); public void lock() { Thread currentThread = Thread.currentThread(); // 如果锁未被占用，则设置当前线程为锁的拥有者 while (owner.compareAndSet(null, currentThread)) { } } public void unlock() { Thread currentThread = Thread.currentThread(); // 只有锁的拥有者才能释放锁 owner.compareAndSet(currentThread, null); } } SimpleSpinLock里有一个owner属性持有锁当前拥有者的线程的引用

3 月，跳不动了？>>> 在并发编程中CAS的缺点和问题，如ABA问题，自旋锁消耗问题、多变量共享一致性问题 ABA： 问题描述：线程t1将它的值从A变为B，再从B变为A。同时有线程t2要将值从A变为C。但CAS检查的时候会发现没有改变，但是实质上它已经发生了改变 。可能会造成数据的缺失。 解决方法：CAS还是类似于乐观锁，同数据乐观锁的方式给它加一个版本号或者时间戳，如AtomicStampedReference 自旋消耗资源： 问题描述：多个线程争夺同一个资源时，如果自旋一直不成功，将会一直占用CPU。 解决方法：破坏掉for死循环，当超过一定时间或者一定次数时，return退出。JDK8新增的LongAddr,和ConcurrentHashMap类似的方法。当多个线程竞争时，将粒度变小，将一个变量拆分为多个变量，达到多个线程访问多个资源的效果，最后再调用sum把它合起来。 虽然base和cells都是volatile修饰的，但感觉这个sum操作没有加锁，可能sum的结果不是那么精确。 public long sum() { Cell[] as = cells; Cell a; long sum = base; if (as != null) { for (int i = 0; i < as.length; ++i) { if ((a = as[i]) != null) sum

3 月，跳不动了？>>> 目前在Java中存在两种锁机制：synchronized和Lock，Lock接口及其实现类是JDK5增加的内容，其作者是大名鼎鼎的并发专家Doug Lea。本文并不比较synchronized与Lock孰优孰劣，只是介绍二者的实现原理。 数据同步需要依赖锁，那锁的同步又依赖谁？synchronized给出的答案是在软件层面依赖JVM，而Lock给出的方案是在硬件层面依赖特殊的CPU指令，大家可能会进一步追问：JVM底层又是如何实现synchronized的？ 本文所指说的JVM是指Hotspot的6u23版本，下面首先介绍synchronized的实现： synrhronized关键字简洁、清晰、语义明确，因此即使有了Lock接口，使用的还是非常广泛。其应用层的语义是可以把任何一个非null对象作为"锁"，当synchronized作用在方法上时，锁住的便是对象实例（this）；当作用在静态方法时锁住的便是对象对应的Class实例，因为Class数据存在于永久带，因此静态方法锁相当于该类的一个全局锁；当synchronized作用于某一个对象实例时，锁住的便是对应的代码块。在HotSpot JVM实现中，锁有个专门的名字：对象监视器。 1. 线程状态及状态转换 当多个线程同时请求某个对象监视器时，对象监视器会设置几种状态用来区分请求的线程：