资源竞速(Race Conditions)和临界区(Critical Sections)

  • 临界区
  • 临界区的资源竞速
  • 避免资源竞速
  • 临界区的吞吐量

critical section是每个线程中访问临界资源的那段代码,不论是硬件临界资源,还是软件临界资源,多个线程必须互斥地对它进行访问。
资源竞速就是可能在由于在访问临界区时没有互斥的访问而导致的特殊情况。

如果多个线程在临界区的执行结果可能因为代码的执行顺序不同而出现不同的结果,我们就说这时候在临界区出现了资源竞速的情况。

我们接下来会详细的介绍资源竞速和临界区的概念

临界区

当多个线程访问相同资源的时候,就会出现问题。比如说访问相同的内存区域(变量,数组或者对象),系统资源(数据库,文件等)
而且,一般来说,只在多个线程对这个资源进行写操作的时候才会出现问题,如果是简单的读操作,不改变资源的话,显然是不会出现问题的。
Here is a critical section Java code example that may fail if executed by multiple threads simultaneously:
下面这段临界区的代码,如果被多个线程执行就可能出现问题:

 public class Counter {

     protected long count = 0;

     public void add(long value){
         this.count = this.count + value;
     }
  }

我们假设有两个线程A和B同时执行add方法在相同的实例上,我们无法获知什么时候操作系统进行线程的切换,而且代码中的add操作对jvm来说不是原子操作,而是由一下类似的几步指令:

  • load,从内存中将this.count的值load到寄存器上
  • 在寄存器上进行加法运算
  • 将寄存器的值写回到内存中

我们看看如果按下面的执行顺序,结果会是什么样?

   A:  Reads this.count into a register (0)
   B:  Reads this.count into a register (0)
   B:  Adds value 2 to register
   B:  Writes register value (2) back to memory. this.count now equals 2
   A:  Adds value 3 to register
   A:  Writes register value (3) back to memory. this.count now equals 3

我们如果按照上述的执行顺序,counter最后结果会是3,但我们都知道最后的值应该为5才对,但由于上述指令是交叉执行的,所以最后会导致不一样的结果。

临界区的资源竞速

add方法中包括了一个临界区,当多个线程访问临界区时,就会出现资源竞速的问题。
更标准的说,当两个或多个线程竞争同一个资源时,对资源的访问顺序就变的很关键了,这就是资源竞速的问题,一段代码块导致资源竞速的问题就是临界区代码。

避免资源竞速

为了避免资源竞速的问题,我们必须保证临界区的代码必须原子性。这就意味着当一个线程进入临界区执行时,其他线程不能进入这个线程执行,除非那个线程离开了临界区,也就是说只有一个线程能在临界区执行在某个时刻。

为了避免资源竞速的问题,我们可以使用synchronized关键字同步代码块,或者使用lock对象,或者使用atomic variables。我们将在后续文章中讲述。

临界区的吞吐量

对于小的临界区,我们直接将整个代码块标为synchronized就可以避免资源竞速了。但是对于较大的临界区,我们为了执行效率,最好将代码分为小的临界区,并分别同步的不同的临界区,因为我们知道synchronized的关键字的影响是比较大的。如果我们直接同步整个临界区,很可能会影响临界区的吞吐量。
我们通过下面这个例子来具体讲述:

public class TwoSums {
    
    private int sum1 = 0;
    private int sum2 = 0;
    
    public void add(int val1, int val2){
        synchronized(this){
            this.sum1 += val1;   
            this.sum2 += val2;
        }
    }
}

为了避免资源竞速,我们将两个加法操作同步了,这样的话,在某一个时刻,只有一个时刻可以执行加法操作。

然而,因为两个sum变量都是互相独立的,所以我们可以将两个变量分别分成不同的同步块中:

public class TwoSums {
    
    private int sum1 = 0;
    private int sum2 = 0;

    private Integer sum1Lock = new Integer(1);
    private Integer sum2Lock = new Integer(2);

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

推荐阅读更多精彩内容