Java线程安全

问题的起源

首先,Java并发的问题要从JMM(Java Memory Model)讲起,先上一张JMM的结构图:


JMM.png

在Java内存模型中,分为主内存和线程工作内存,线程使用共享数据时,都是先从主内存中拷贝到工作内存,使用完成之后再写入主内存,可以理解为线程之间通讯是通过共享内存的方式实现的。
在多线程环境下,不同线程对同一份数据操作,就可能会产生不同线程中数据状态不一致的情况,这就是线程安全问题的定义或者说原因。
要实现线程安全,需要保证数据操作的两个特性:

  • 原子性:对数据的操作不会受其他线程打断,意味着一个线程操作数据过程中不会插入其他线程对数据的操作
  • 可见性:当线程修改了数据的状态时,能够立即被其他线程知晓,即数据修改后会立即写入主内存,后续其他线程读取时就能得知数据的变化
    以上两个特性结合起来,其实就相当于同一时刻只能有一个线程去进行数据操作并将结果写入主存,这样就保证了线程安全。
    接下来结合Java中线程安全的实现来看。

Volatile:可见性的保证

volatile有两点特性,第一是保证变量对所有线程的可见性,对于普通变量,一个线程对其修改后并不保证会立即写入主存,只有当写入主存之后才会对其他线程可见,而volatile关键字能够保证线程修改完变量立即写回主存,而且每个线程在使用变量前都必须先从主存刷新数据,这样就保证了修改的可见性。
第二点时禁止指令的重排序,Java编译器会对无结果依赖的代码指令进行重排序,下面这段伪代码可以说明指令重排序导致的并发问题:

//线程A执行
void init(){
  list = new ArrayList<>();
  ...  
  init = true;
}

//线程B执行
void run(){
  if(init) //dosomething
}

init = true与其他代码无结果关联,所以可能被重排序到前面,导致线程B执行时认为初始化完成但是list并没有赋值,如果用volatile关键字就能避免这种指令重排序。
volatile虽然保证了可见性,但并没有保证操作的原子性,还是会出现A、B线程同时读取到共享数据,然后各自修改导致结果覆盖的问题,所以无法保证线程安全。
volatile实际适用场景主要可以结合CAS操作,提高并发的性能,就如同Java concurrent类库中的用法,因为volatile的性能是很轻量的,能够避免CAS操作因为数据的可见性问题而导致失败。

Synchronized

Synchronized主要是通过对象锁的方式来实现线程安全(这边的锁是指虚拟机实现的锁,和Java Lock类库不是一个概念),修饰静态方法获取的是Class对象的锁,修饰方法是获取当前对象this的锁,修饰括号内容是获取括号内对象的锁。
对象锁分为偏向锁、轻量级锁、重量级锁,锁信息记录在对象头中(Mark Word,详情参考表中结构),对应锁标志位为轻量级锁:00,重量级锁:10,GC标志:11,偏向锁:01。


Mark Word

线程获取对象锁都是通过CAS操作修改对象头中的指向所记录的指针和锁状态,偏向锁、轻量级锁、重量级锁的分类主要在于加锁、解锁时的流程不同,性能开支不同罢了。


对象锁

其实可以看到,对象锁的获取都是通过CAS修改对象头来实现的,那为什么还要分这么多种类呢?其实他们的加锁解锁过程还是有区别的,使用场景也不一样:

偏向锁

锁不会主动释放,只有当出现竞争时,才会去检查是否需要释放或者重新偏向锁,主要应用场景适用于基本只有一个线程访问同步代码块,可以无限重复获取偏向锁,大家可以看到其实在竞争偏向锁时需要在暂停当前持有锁的线程的(当然是要在安全点暂停),所以在高并发高竞争的情况下可以考虑关闭偏向锁。

轻量级锁&重量级锁

轻量级锁在竞争锁失败时,会通过自旋的方式尝试获取锁,而重量级锁竞争失败后会直接阻塞线程。所以,轻量级锁适用于那些同步代码块执行速度很快的场景,而重量级锁则对应同步代码块执行时间长的场景。

Concurrent

Java类库中有专门的concurrent包实现线程安全,核心类就是AQS(AbstractQueuedSynchronizer),一个抽象队列同步器,相当于一个模板,类库中ReentantLock等都是通过它来实现的。
AQS的核心原理:
维护一个volatile state作为锁标志计数,同时维护一个Node链表作为等待节点队列,锁的请求释放流程如下:


AQS

主要的流程就是这么简单,当然要看代码实现细节包括很多细节:公平锁/非公平锁的区别、超时机制的实现、Node链表的哨兵技巧、Node的状态迁移、共享锁的实现、读写锁高低位的技巧等,其实就是某几行代码的区别,魔鬼在细节里面。Condition的实现和锁本身队列的维护类似,就不多做赘述了。

综上

Java中的线程安全从JMM,到同步机制的实现,整体就有个大致的印象了,下次再分析分析线程安全容器和线程池的实现吧,喜欢的点个赞哟~

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,651评论 6 501
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,468评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,931评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,218评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,234评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,198评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,084评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,926评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,341评论 1 311
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,563评论 2 333
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,731评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,430评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,036评论 3 326
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,676评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,829评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,743评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,629评论 2 354

推荐阅读更多精彩内容