建议73:避免锁定不恰当的同步对象
在C#中,让线程同步的另一种编码方式就是使用线程锁。线程锁的原理,就是锁住一个资源,使得应用程序在此刻只有一个线程访问该资源。通俗地讲,就是让多线程变成单线程。在C#中,可以将被锁定的资源理解成new出来的普通CLR对象。
既然需要锁定的资源就是C#中的一个对象,我们就该仔细思考,到底什么样的对象能够成为一个锁对象(也叫同步对象)?在选择同步对象的时候,应当始终注意以下几点:
- 同步对象在需要同步的多个线程中是可见的同一个对象。
- 在非静态方法中,静态变量不应作为同步对象。
- 值类型对象不能作为同步对象。
- 避免将字符串作为同步对象。
- 降低同步对象的可见性。
下面分别详细介绍以上五个注意事项。
第一个注意事项:需要锁定的对象在多个线程中是可见的,而且是同一个对象。“可见的”这是显而易见的,如果对象不可见,就不能被锁定。“同一个对象”,这也很容易理解,如果锁定的不是同一个对象,那又如何来同步两个对象呢?虽然理解起来简单,但不见得我们在这上面就不会犯错误。为了帮助大家理解本建议的内容,我们先模拟一个必须使用到锁的场景:在遍历一个集合的过程中,同时在另外一个线程中删除集合中的某项。下面这个例子中,如果没有lock语句,将会抛出异常InvalidOperationException:“集合已修改;可能无法执行枚举”:
这是一个Winform窗体应用程序,需要演示的功能在按钮的单击事件中。对象syncObj对于线程t1和t2来说,在CLR中肯定是同一个对象。所以,上面的示例运行是没有问题的。
现在,我们将此示例重构。将实际的工作代码移到一个类型SampleClass中,该示例要在多个SampleClass实例间操作一个静态字段,如下所示:
该示例运行起来会抛出异常InvalidOperationException:
“集合已修改;可能无法执行枚举。”
查看类型SampleClass的方法StartT1和StartT2,方法内部锁定的是SampleClass的实例变量syncObject。实例变量意味着,每创建一个SampleClass的实例都会生成一个syncObject对象。在本例中,调用者一共创建了两个SampleClass实例,继而分别调用:
也就是说,以上代码锁定的是两个不同的syncObject,这等于完全没有达到两个线程锁定同一个对象的目的。要修正以上错误,只要将syncObject变成static就可以了。
另外,思考一下lock(this),我们同样不建议在代码中编写这样的代码。如果两个对象的实例分别执行了锁定的代码,实际锁定的也就会是两个对象,完全不能达到同步的目的。
第二个注意事项:在非静态方法中,静态变量不应作为同步对象。也许有读者会问,前面曾说到,要修正第一个注意事项中的示例问题,需要将syncObject变成static。这似乎和本注意事项有矛盾。事实上,第一个注意事项中的示例代码仅仅出于演示的目的,在实际应用中,我们强烈建议不要编写此类代码。在编写多线程代码时,要遵循这样的一个原则:类型的静态方法应当保证线程安全,非静态方法不需实现线程安全。
FCL中的绝大部分类都遵循了这个原则。像上一个示例中,如果将syncObject变成static,就相当于让非静态方法具备了线程安全性,这带来的一个问题是,如果应用程序中该类型存在多个实例,在遇到这个锁的时候,它们都会产生同步,而这可能不是开发者所愿意看到的。第二个注意事项实际也可以归纳到第一个注意事项中。
第三个注意事项:值类型对象不能作为同步对象。值类型在传递到另一个线程的时候,会创建一个副本,这相当于每个线程锁定的也是两个对象。因此,值类型对象不能作为同步对象。
第四个注意事项:锁定字符串是完全没有必要的,而且相当危险。这整个过程看上去和值类型正好相反。字符串在CLR中会被暂存到内存里,如果有两个变量被分配了相同内容的字符串,那么这两个引用会被指向同一块内存。所以,如果有两个地方同时使用了lock(“abc”),那么它们实际锁定的是同一个对象,这会导致整个应用程序被阻滞。
第五个注意事项:降低同步对象的可见性。可见范围最广的一种同步对象是typeof(SampleClass)。typeof方法所返回的结果(也就是类型的type)是SampleClass的所有实例所共有的,即:所有实例的type都指向typeof方法的结果。这样一来,如果我们lock(typeof(SampleClass)),当前应用程序中所有SampleClass的实例线程将会全部被同步。这样编码完全没有必要,而且这样的同步对象太开放了。
一般来说,同步对象也不应该是一个公共变量或属性。在FCL的早期版本中,一些常用的集合类型(如ArrayList)提供了公共属性SyncRoot,让我们锁定以便进行一些线程安全的操作。所以你一定会觉得我们刚才的结论不正确。其实不然,ArrayList操作的大部分应用场景不涉及多线程同步,所以它的方法更多的是单线程应用场景。线程同步是一个非常耗时(低效)的操作。若ArrayList的所有非静态方法都要考虑线程安全,那么ArrayList完全可以将这个SyncRoot变成静态私有的。现在它将SyncRoot变为公开的,是让调用者自己去决定操作是否需要线程安全。我们在编写代码时,除非有这样的要求,否则就应该始终考虑降低同步对象的可见性,将同步对象藏起来,只开放给自己或自己的子类就够了(需要开放给子类的情况其实也不多)。
--------------------------
本文节选自《编写高质量代码:改善C#程序的157个建议》,本书从语言本身、程序的设计和架构、编码规范和编程习惯等三大方面对C#程序员遇到的经典问题给出了经验性的解决方案,为C#程序员如何编写更高质量的C#代码提供了157条极为宝贵的建议。
作者:陆敏技,资深软件工程师、项目经理和架构师,从事软件开发工作近10年。尤其精通微软技术,对C#、WPF、WCF、ASP.NET和.NET技术有十分深入的研究,曾参与和主导了大量的相关项目的架构和开发工作,积累了丰富的经验。本书配套源代码下载:http://www.cnblogs.com/luminji
第一部分 语言篇
第1章 基本语言要素 / 2
建议1:正确操作字符串 / 2
建议2:使用默认转型方法 / 6
建议3:区别对待强制转型与as和is / 9
建议4:TryParse比Parse好 / 12
建议5:使用int?来确保值类型也可以为null / 15
建议6:区别readonly和const的使用方法 / 16
建议7:将0值作为枚举的默认值 / 19
建议8:避免给枚举类型的元素提供显式的值 / 20
建议9:习惯重载运算符 / 22
建议10:创建对象时需要考虑是否实现比较器 / 23
建议11:区别对待==和Equals / 27
建议12:重写Equals时也要重写GetHashCode / 29
建议13:为类型输出格式化字符串 / 32
建议14:正确实现浅拷贝和深拷贝 / 36
建议15:使用dynamic来简化反射实现 / 40
第2章 集合和LINQ / 43
建议16:元素数量可变的情况下不应使用数组 / 43
建议17:多数情况下使用foreach进行循环遍历 / 45
建议18:foreach不能代替for / 51
建议19:使用更有效的对象和集合初始化 / 53
建议20:使用泛型集合代替非泛型集合 / 54
建议21:选择正确的集合 / 57
建议22:确保集合的线程安全 / 61
建议23:避免将List<T>作为自定义集合类的基类 / 64
建议24:迭代器应该是只读的 / 67
建议25:谨慎集合属性的可写操作 / 68
建议26:使用匿名类型存储LINQ查询结果 / 70
建议27:在查询中使用Lambda表达式 / 73
建议28:理解延迟求值和主动求值之间的区别 / 75
建议29:区别LINQ查询中的IEnumerable<T>和IQueryable<T> / 78
建议30:使用LINQ取代集合中的比较器和迭代器 / 80
建议31:在LINQ查询中避免不必要的迭代 / 83
第3章 泛型、委托和事件 / 86
建议32:总是优先考虑泛型 / 86
建议33:避免在泛型类型中声明静态成员 / 88
建议34:为泛型参数设定约束 / 90
建议35:使用default为泛型类型变量指定初始值 / 92
建议36:使用FCL中的委托声明 / 94
建议37:使用Lambda表达式代替方法和匿名方法 / 96
建议38:小心闭包中的陷阱 / 99
建议39:了解委托的实质 / 103
建议40:使用event关键字为委托施加保护 / 106
建议41:实现标准的事件模型 / 108
建议42:使用泛型参数兼容泛型接口的不可变性 / 109
建议43:让接口中的泛型参数支持协变 / 111
建议44:理解委托中的协变 / 112
建议45:为泛型类型参数指定逆变 / 114
第4章 资源管理和序列化 / 116
建议46:显式释放资源需继承接口IDisposable / 116
建议47:即使提供了显式释放方法,也应该在终结器中提供隐式清理 / 119
建议48:Dispose方法应允许被多次调用 / 120
建议49:在Dispose模式中应提取一个受保护的虚方法 / 121
建议50:在Dispose模式中应区别对待托管资源和非托管资源 / 123
建议51:具有可释放字段的类型或拥有本机资源的类型应该是可释放的 / 124
建议52:及时释放资源 / 125
建议53:必要时应将不再使用的对象引用赋值为null / 127
建议54:为无用字段标注不可序列化 / 131
建议55:利用定制特性减少可序列化的字段 / 136
建议56:使用继承ISerializable接口更灵活地控制序列化过程 / 137
建议57:实现ISerializable的子类型应负责父类的序列化 / 140
第5章 异常与自定义异常 / 144
建议58:用抛出异常代替返回错误代码 / 144
建议59:不要在不恰当的场合下引发异常 / 147
建议60:重新引发异常时使用Inner Exception / 150
建议61:避免在finally内撰写无效代码 / 151
建议62:避免嵌套异常 / 157
建议63:避免“吃掉”异常 / 160
建议64:为循环增加Tester-Doer模式而不是将try-catch置于循环内 / 161
建议65:总是处理未捕获的异常 / 162
建议66:正确捕获多线程中的异常 / 166
建议67:慎用自定义异常 / 168
建议68:从System.Exception或其他常见的基本异常中派生异常 / 170
建议69:应使用finally避免资源泄漏 / 172
建议70:避免在调用栈较低的位置记录异常 / 175
第6章 异步、多线程、任务和并行 / 177
建议71:区分异步和多线程应用场景 / 177
建议72:在线程同步中使用信号量 / 180
建议73:避免锁定不恰当的同步对象 / 184
建议74:警惕线程的IsBackground / 188
建议75:警惕线程不会立即启动 / 189
建议76:警惕线程的优先级 / 191
建议77:正确停止线程 / 193
建议78:应避免线程数量过多 / 194
建议79:使用ThreadPool或BackgroundWorker代替Thread / 196
建议80:用Task代替ThreadPool / 198
建议81:使用Parallel简化同步状态下Task的使用 / 202
建议82:Parallel简化但不等同于Task默认行为 / 204
建议83:小心Parallel中的陷阱 / 205
建议84:使用PLINQ / 208
建议85:Task中的异常处理 / 209
建议86:Parallel中的异常处理 / 214
建议87:区分WPF和WinForm的线程模型 / 216
建议88:并行并不总是速度更快 / 220
建议89:在并行方法体中谨慎使用锁 / 222
第二部分 架构篇
第7章 成员设计 / 226
建议90:不要为抽象类提供公开的构造方法 / 226
建议91:可见字段应该重构为属性 / 226
建议92:谨慎将数组或集合作为属性 / 227
建议93:构造方法应初始化主要属性和字段 / 228
建议94:区别对待override和new / 229
建议95:避免在构造方法中调用虚成员 / 235
建议96:成员应优先考虑公开基类型或接口 / 236
建议97:优先考虑将基类型或接口作为参数传递 / 237
建议98:用params减少重复参数 / 237
建议99:重写时不应使用子类参数 / 238
建议100:静态方法和实例方法没有区别 / 239
建议101:使用扩展方法,向现有类型“添加”方法 / 240
第8章 类型设计 / 243
建议102:区分接口和抽象类的应用场合 / 243
建议103:区分组合和继承的应用场合 / 245
建议104:用多态代替条件语句 / 248
建议105:使用私有构造函数强化单例 / 251
建议106:为静态类添加静态构造函数 / 253
建议107:区分静态类和单例 / 255
建议108:将类型标识为sealed / 255
建议109:谨慎使用嵌套类 / 256
建议110:用类来代替enum / 257
建议111:避免双向耦合 / 260
建议112:将现实世界中的对象抽象为类,将可复用对象圈起来就是命名空间 / 262
第9章 安全性设计 / 264
建议113:声明变量前考虑最大值 / 264
建议114:MD5不再安全 / 265
建议115:通过HASH来验证文件是否被篡改 / 268
建议116:避免用非对称算法加密文件 / 269
建议117:使用SSL确保通信中的数据安全 / 273
建议118:使用SecureString保存密钥等机密字符串 / 284
建议119:不要使用自己的加密算法 / 289
建议120:为程序集指定强名称 / 289
建议121:为应用程序设定运行权限 / 291
第三部分 编码规范及习惯
第10章 命名规范 / 296
建议122:以<Company>.<Component>为命名空间命名 / 296
建议123:程序集不必与命名空间同名 / 296
建议124:考虑在命名空间中使用复数 / 297
建议125:避免用FCL的类型名称命名自己的类型 / / 297
建议126:用名词和名词组给类型命名 / 298
建议127:用形容词组给接口命名 / 299
建议128:考虑让派生类的名字以基类名字作为后缀 / 300
建议129:泛型类型参数要以T作为前缀 / 300
建议130:以复数命名枚举类型,以单数命名枚举元素 / 301
建议131:用PascalCasing命名公开元素 / 302
建议132:考虑用类名作为属性名 / 302
建议133:用camelCasing命名私有字段和局部变量 / 303
建议134:有条件地使用前缀 / 304
建议135: 考虑使用肯定性的短语命名布尔属性 / 305
建议136:优先使用后缀表示已有类型的新版本 / 306
建议137:委托和事件类型应添加上级后缀 / 307
建议138:事件和委托变量使用动词或形容词短语命名 / 308
建议139:事件处理器命名采用组合方式 / 309
第11章 代码整洁 / 311
建议140:使用默认的访问修饰符 / 311
建议141:不知道该不该用大括号时,就用 / 312
建议142:总是提供有意义的命名 / 314
建议143:方法抽象级别应在同一层次 / 315
建议144:一个方法只做一件事 / 316
建议145:避免过长的方法和过长的类 / 317
建议146:只对外公布必要的操作 / 318
建议147:重构多个相关属性为一个类 / 319
建议148:不重复代码 / 320
建议149:使用表驱动法避免过长的if和switch分支 / 321
建议150:使用匿名方法、Lambda表达式代替方法 / 324
建议151:使用事件访问器替换公开的事件成员变量 / 325
建议152:最少,甚至是不要注释 / 326
建议153:若抛出异常,则必须要注释 / 326
第12章 规范开发行为 / 327
建议154:不要过度设计,在敏捷中体会重构的乐趣 / 327
建议155:随生产代码一起提交单元测试代码 / 336
建议156:利用特性为应用程序提供多个版本 / 342
建议157:从写第一个界面开始,就进行自动化测试 / 344
分享到:
相关推荐
这份资料《改善C#的157个建议》提供了一系列实用的技巧和最佳实践,旨在帮助开发者提升代码的可读性、性能和维护性。以下是一些核心知识点的概述: 1. **命名规范**:遵循一致的命名规则是提高代码可读性的基础。如...
《编写高质量代码:改善C#程序的150个建议》是一本专注于提升C#编程实践的书籍,旨在帮助开发者优化代码,提升软件项目的整体质量和可维护性。这本书的建议覆盖了从基本语法到高级设计模式,从代码组织到调试技巧的...
《编写高质量代码:改善c#程序的157个建议》是c#程序员进阶修炼的必读之作,包含的全部都是c#编码的最佳实践,从语言本身、程序的设计和架构、编码规范和编程习惯等三大方面对c#程序员遇到的经典问题给出了经验性的...
《编写高质量代码:改善C#程序的157个建议》是一本专注于提升C#编程实践的书籍。这本书深入探讨了在开发过程中如何通过优化代码结构、提高代码可读性、减少潜在错误以及提升性能来改善C#程序的质量。下面我们将依据...
由于我无法直接获取文件内容,因此我将基于您提供的标题、描述和标签来生成关于如何编写高质量C#...在学习和应用这些知识点的过程中,可以参考《编写高质量代码:改善C#程序的157个建议》这本书来获得更多细节和实例。
《编写高质量代码:改善C#程序的157个建议》是一本专注于提升C#编程实践的书籍,它为开发者提供了丰富的指导,旨在帮助他们写出更高效、更易读、更易于维护的代码。这本书结合了理论与实践,涵盖了从基本编程习惯到...
在编程领域,代码质量至关重要,它直接影响到软件的可维护性、可扩展性和性能。针对C#编程语言,以下是从“提高代码质量的157个建议...阅读“编写高质量代码改善C#程序的157个建议”PDF,将提供更为详细和全面的指导。
本书是一本关于如何编写高质量C#代码的工具书,列举的问题非常典型,给出的建议也非常实用,其中的每一条建议都有可能在我们编写下一行代码的时候用到。你可以将此书搁置在案头,以便有需要的时候随时查阅。
马伟的《编写高质量代码(改善C程序代码的 125个建议)》是华章“编写高质量代码”系列的第7本,之前已经出版C++、C#、Java、Pvthon、 ObjectiVe-c、Javascript相关*作。在通往“C语 言技术殿堂”的路上,本书将为你...
"编写高质量代码之改善C#程序的157个建议"是一个宝贵的资源,它提供了丰富的指导,帮助程序员提升C#编程技巧。下面,我们将根据这个主题,探讨一些关键的知识点: 1. **代码规范与风格**:遵循一致的命名规则,如...
以上就是针对"C#编写高质量代码改善C#程序的157个建议"的详细解析,涵盖多个方面,旨在帮助开发者构建出更稳定、高效、易于维护的C#应用程序。通过实践这些建议,不仅可以提高个人编程技能,也能提升整个项目团队的...
《Effective C#中文版:改善C#程序的50种方法》是一本专注于提升C#编程技巧和优化代码质量的指南。这本书的核心是通过50个独立但相互关联的建议,帮助开发者深入理解C#语言的特性,并利用这些特性编写出更加高效、可...
本书适合那些有一定C#基础,并希望在技术上得到大幅提升的程序员。 本书并没有讲述C#中的...书中的大多数建议实战性很强,要完全理解其中的奥妙,首先应该动手写一写示例程序,或许在调试程序的过程中就会得到启发。
改善C#的157个建议编写高质量代码_源代码合集,这些实例均采用4.0框架,请运行使用Release模式;部分TIP由于简单未给出源码;这157个建议的源码涉及到语言篇、集合和LINQ、泛型、委托和事件、资源管理和序列化、异常...
《改善C#程序的157个建议》是一本针对C#程序员的实践指南,旨在帮助开发者提升代码质量,优化程序性能。这本书分为三个部分,分别涵盖了从基础到高级的各种编程技巧和最佳实践。 1. **使用Framework 4.0**: .NET ...
《Effective C#中文版:改善C#程序的50种方法》(以下简称《Effective C#》)这本书深入探讨了C#编程的各个方面,旨在帮助开发者在编写程序时避免常见的错误,提升代码质量,优化编程实践。书中的每一条建议都源自...
《Effective C#:中文版 改善C#程序的50种方法》是一本深入探讨C#编程实践的书籍,作者Bill Wagner通过50个独立的条目,为程序员提供了优化C#代码、提高程序效率和可维护性的宝贵建议。这本书是C#开发者提升技能、...
《More Effective C#中文版 改善C#程序的50个具体办法》是一本针对C#编程语言的进阶指南,由业界资深专家撰写,旨在帮助开发者提升代码质量和效率。书中通过50个具体的实践建议,深入浅出地探讨了如何在C#开发过程中...