c#Lock学习笔记

转自 http://www.cnblogs.com/tianma3798/p/6290158.html

参考官网  https://docs.microsoft.com/zh-cn/dotnet/csharp/language-reference/keywords/lock-statement

一、lock关键词说明

1. lock 关键字将语句块标记为临界区,方法是获取给定对象的互斥锁,执行语句,然后释放该锁。

2. lock 语句块锁定,功能等同于

Monitor.Enter(obj); 
//代码段
Monitor.Exit(obj);

3. lock语句块锁定和Monitor线程锁,不能跨进程同步

二、备注

lock 关键字可确保当一个线程位于代码的临界区时,另一个线程不会进入该临界区。 如果其他线程尝试进入锁定的代码,则它将一直等待(即被阻止),直到该对象被释放。

线程 这节讨论了线程处理。

lock 关键字在块的开始处调用 Enter,而在块的结尾处调用 Exit。 ThreadInterruptedException 引发,如果 Interrupt 中断等待输入 lock 语句的线程。

通常,应避免锁定 public 类型,否则实例将超出代码的控制范围。 常见的结构 lock (this)lock (typeof (MyType)) 和 lock ("myLock") 违反此准则:

  • 如果实例可以被公共访问,将出现 lock (this) 问题。

  • 如果 MyType 可以被公共访问,将出现 lock (typeof (MyType)) 问题。

  • 由于进程中使用同一字符串的任何其他代码都将共享同一个锁,所以出现 lock("myLock") 问题。

最佳做法是定义 private 对象来锁定, 或 private static 对象变量来保护所有实例所共有的数据。

在 lock 语句的正文不能使用 等待 关键字。

三、特别说明

1.lock语句中锁定的必须是引用类型的对象,不能是值类型

(1)值类型 一般都在线程函数自己的栈里,每个线程局部栈是不一样的,互相之间不会有影响,所以不用锁定
一个特例,引用类型值类型字段在堆里,但可以通过lock那个引用类型对象就可以实现了。

(2)引用可以指向同一个对象,而值类型的变量每次都是不同的

(3)他要的就是引用类型,如果你传一个值类型,会装箱,下次代码运行到这里,又会装箱,两次不是同一个对象,所以锁不住。这个解释最靠谱

2.为了避免死锁,lock的对象需要是private对象

3.为了避免lock对象的唯一性,通lock的对象为 private static或者 private readonly static

第二章,什么时候需要锁

转自 http://www.cnblogs.com/plin2008/archive/2009/06/24/1510057.html

      首先要理解锁定是解决竞争条件的,也就是多个线程同时访问某个资源,造成意想不到的结果。比如,最简单的情况是,一个计数器,两个线程 同时加一,后果就是损失了一个计数,但相当频繁的锁定又可能带来性能上的消耗,还有最可怕的情况死锁。那么什么情况下我们需要使用锁,什么情况下不需要 呢?

      1)只有共享资源才需要锁定
      只有可以被多线程访问的共享资源才需要考虑锁定,比如静态变量,再比如某些缓存中的值,而属于线程内部的变量不需要锁定。 

      2)多使用lock,少用Mutex
      如果你一定要使用锁定,请尽量不要使用内核模块的锁定机制,比如.NET的Mutex,Semaphore,AutoResetEvent和 ManuResetEvent,使用这样的机制涉及到了系统在用户模式和内核模式间的切换,性能差很多,但是他们的优点是可以跨进程同步线程,所以应该清 楚的了解到他们的不同和适用范围。

      3)了解你的程序是怎么运行的
      实际上在web开发中大多数逻辑都是在单个线程中展开的,一个请求都会在一个单独的线程中处理,其中的大部分变量都是属于这个线程的,根本没有必要考虑锁定,当然对于ASP.NET中的Application对象中的数据,我们就要考虑加锁了。

      4)把锁定交给数据库
      数 据库除了存储数据之外,还有一个重要的用途就是同步,数据库本身用了一套复杂的机制来保证数据的可靠和一致性,这就为我们节省了很多的精力。保证了数据源 头上的同步,我们多数的精力就可以集中在缓存等其他一些资源的同步访问上了。通常,只有涉及到多个线程修改数据库中同一条记录时,我们才考虑加锁。 

      5)业务逻辑对事务和线程安全的要求
      这 条是最根本的东西,开发完全线程安全的程序是件很费时费力的事情,在电子商务等涉及金融系统的案例中,许多逻辑都必须严格的线程安全,所以我们不得不牺牲 一些性能,和很多的开发时间来做这方面的工作。而一般的应用中,许多情况下虽然程序有竞争的危险,我们还是可以不使用锁定,比如有的时候计数器少一多一, 对结果无伤大雅的情况下,我们就可以不用去管它。

三、小题练练

转自 http://www.fx114.net/qa-276-77022.aspx

看看以下会不会产生死锁:

public class A
    {
        private object obj = new object();
        public void Test(int i)
        {
            lock (obj)
            {
                if (i>10)
                {
                    i--;
                    Test(i);
                }
                else
                {
                    Console.WriteLine(i);
                }
            }
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            A a = new A();
            a.Test(15);
            Console.ReadKey();
        }
    }

你的答案是会产生死锁吗?可以理解,因为也许你以前一直以为外层递归被锁住后,不允许在访问里边的代码快,而由于递归,有需要等待外层递归解锁,所以由此造成死锁,现在才知道这种理解是错误的;结果是永远不会出现死锁,因为lock的本质是对于不同的线程来说的,或者这个所的所有权已经归该现成所有,它可以任意使用该锁

说道这里又想多说一点,假如另一个线程在另一个函数里操作同一个obj,这是obj可以被访问吗在锁释放之前,如下代码:

public class Test
    {
        string name = "Empty";

        public Test()
        {
 
        }

        public string Name
        {
            get
            {
                return this.name;
            }
            set
            {
                this.name = value;
            }
        }
    }

    public class A
    {
        Test test = new Test();

        public void OneMethod()
        {
            lock (this.test)
            {
                Console.WriteLine("one thread come in,sleep for 10 seconds");
                Console.WriteLine(test.Name);
                Thread.Sleep(10000);//如果第二个线程可以在锁住期间可以对test对象操作,那么线程二应该在10000毫秒之内已经输出
                test.Name = "One thread output";
                Console.WriteLine(test.Name);
            }
        }

        public void TwoMethod()
        {
            Thread.Sleep(100);//为了确保第一个线程先锁住后在操作test对象
            Console.WriteLine("two thread come in");//假如由于线程一锁住test对象而不能对test操作的话,那么要等待10000毫秒
            test.Name = "Two thread output";
            Console.WriteLine(test.Name);
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            A a = new A();
            Thread one = new Thread(new ThreadStart(a.OneMethod));
            Thread two = new Thread(new ThreadStart(a.TwoMethod));
            one.Start();
            two.Start();
            Console.ReadKey();
        }
    }

其输出结果为:

one thread come in,sleep for 10 seconds

Empty

two thread come in//在第一个线程之间操作

Two thread output//在第一个线程锁住test对象之中,改变的test。Name属性值,说明锁中test时将可以对test进行操作

One thread output

答案是:test对象在别的函数中被锁中时,别的线程在被锁块外是可以对test进行操作的

假如我把第二个方法代码做如下修改:

public void TwoMethod()
        {
            Thread.Sleep(100);//为了确保第一个线程先锁住后在操作test对象
            Console.WriteLine("two thread come in");//假如由于线程一锁住test对象而不能对test操作的话,那么要等待10000毫秒
            lock (this.test)
            {
                test.Name = "Two thread output";
                Console.WriteLine(test.Name);
            }            
        }

这时的结果是:

one thread come in,sleep for 10 seconds

Empty

two thread come in//在第一个线程获得锁之间线程二进入了第二方法中的锁之前操作

One thread output//

Twothread output//说明锁test被解锁以后才执行

答案是:一个类中几个方法锁住了同一个对象(该对象必须是引用类型)时,那么第一个获得锁的线程操作,其他线程走到锁对象(哪怕所对象不是在同一个函数中)之前将等待对象被解锁,解锁后才可以进入。打个比喻:test对象相当于一个响应器,lock()锁相当于一个锁,操作系统相当于一个监控器,而一个或多个函数中的锁块相当于一个或多大门,多个线程相当于等在一个或多个大门前的人。假如有任一一个大门被一个人闯进时,那么监控器立即给所有锁上锁lock,锁定所有大门,不准任何人进,直到该人出来,监控器自动打开所有锁,所有大门打开,重复执行第一步,监控器保证只有一个人进入某一个大门。当然如果某一个响应器没有lock,就相当于大门没有锁,就可以对test操作,这种情况就是上一种现象。

二、一道面试题(目前我也不太明白)

转自 https://www.cnblogs.com/myshell/archive/2010/07/18/1780386.html

和https://q.cnblogs.com/q/47290/

public void test(int i) 
 { 
    lock(this) 
   { 
      if (i > 10) 
     { 
          i--; 
          test(i); 
      } 
    } 
 }

分析一下代码,当调用test方法时i>10时是否会引起死锁

不会。终于在《CLR via C#》第二版(中文版,清华大学出版社出版)的第530页中第7行找到了这样的描述:“同样需要引起注意的是线程可以递归拥有同步块”。即同一线程可以递归调用lock语句,这是单线程操作,该线程本身就是锁的拥有者,当再次进入时,自然能获取到进入该锁块的权利。

线程重入问题,lock会与线程关联,如关联上A1线程,那么A1线程重复进入多次也是OK的。但是lock又是独占锁,所以一旦关联上线程,别的线程就无法进入lock代码块。

多线程操作时,会阻塞等待。

原文地址:https://www.cnblogs.com/taoshengyujiu/p/8706513.html