CLR一书译者（PART III和Part V）对Renart勘误的回应

 下面是针对China-pub上Renart之前的“《CLR via C#》中文版民间勘误”做出的回应。 首先非常感谢Renart花精力给出那个勘误，相信对原来的译本是一个很好的补充。下面是我这边请张杰良就第三部分（13-17）和第五部分（30-78）的勘误给出了说明。 在回应中，如果表示接受Renart的意见但觉得也许还可以有另外的表达方式，则给出了另外的译法，主要是让更方便读者从不同角度去理解。如果表示不同意Renart的意见，则给出了原因以及修改后的译法。 注：为了读者方便参考，对于其他部分（第一、二、四部分）Renart的勘误也一并在此列出，但未予以回应。   ———————————————————————————————————————----- 《CLR via C#》中文版民间勘误（一） 对每一个翻译问题，我都提供了自己的建议译法（第9条是个例外），其中有一些可能不是很理想，欢迎批评指正。这几条可能需要首先请各位分析一下：第9、13、18、67和74条。 下面是勘误内容：

1．[位置]：90页-92页。
[类型]：印刷错误。
[说明]：图4.2与图4.3应该互换。图4.4应该使用图4.5中的图。而图4.5应该使用原图4.5并在其基础上作如下修改：在线程堆栈中“[返回地址]”的下方再添两项，依次为“length(Int 32)”和“tally(Int 32)”，并在这两项的右边注明“M2局部变量”。   2．[位置]：131页10行。
[类型]：翻译错误。
[译文原文]：“从友元程序集中访问上述程序集中的internal类型没有什么价值。”
[英文原文]：“Accessing the above assembly's internal types from a friend assembly is trivial.”[建议译文]：从友元程序集中访问上述程序集中的internal类型只是举手之劳。   3．[位置]：132页倒数8行。[类型]：翻译错误。
[译文原文]：“尽管编程语言的编译器忽略可访问性的检查，但是在运行时检验IL代码确保已引用成员的的可访问性是值得的，”
[英文原文]：“Verifying the IL code ensures that a referenced member's accessibility is properly honored at run time, even if a language compiler ignored checking the accessibility.”
[建议译文]：对IL代码的验证确保了，即便在编程语言的编译器忽略可访问性检查的情况下，所引用成员的可访问性在运行时也能得以信守。   4．[位置]：134页倒数8行。
[类型]：翻译错误。
[译文原文]：“而且有一程序开发人员在没有使用源代码控制方法校验类型定义的情况下对源代码进行了签出。”
[英文原文]：“and a programmer checks it out of source control to make changes.”
[评论]：译者自以为是地添加了一大堆自己的想法，恐怕没有人会看得懂他倒底是什么意思。
[建议译文]：“有一个程序员将其从源代码控制工具中签出以进行修改”。  ----- 《CLR via C#》中文版民间勘误（二） ----- 5．[位置]：134页倒数3行至135页5行。
[类型]：翻译错误
[说明]：“代码拆分器（Code splitter）”应为“代码生成器（Code spitter）”。“这些源代码文件中包含可以直接用于构建这些类型的项目的模板（原文：These source code files contain templates that give you a head start at building these kinds of projects）”可译“这些源代码文件中包含了一些模板，它们让你在构建这类项目时享有一个轻松的开始（说明：指有些事情代码生成器已经先替你作好了，你只要在此基础上进行工作就行，因此相对于没有代码生成器的帮助的情况，你就拥有‘head start’）”。“Visual Studio设计中心”应译“Visual Studio设计器”。“事实是（原文：historically）”应译“先前的版本中，”。“以Visual Studio 2005为例（原文：Starting with Visual Studio 2005）”可译“在 Visual Studio 2005中”。另，“以Visual Studio 2005为例，”这一句后的一句是“创建新的项目时”。根据作者自己提供的勘误，应该是“创建Windows窗体、Web窗体和用户控件等的时候”。  
6．[位置]：139页3行。
[类型]： 翻译错误。
[译文原文]：“当然，问题在于，为什么C#编译器只生成call指令，而不是其他指令呢？答案就是因为C#的工作组决定JIT编译器应生成验证所使用的对象的代码，以确定调用不为null。”
[英文原文]：“Of course, the question is, why didn't the C# compiler simply emit the call instruction instead? The answer is because the C# team decided that the JIT compiler should generate code to verify that the object being used to make the call is not null.”
[建议译文]：当然，问题在于，为什么C#编译器不直接生成call指令得了呢？答案是，因为C#工作组决定JIT编译器应该生成一些验证代码，以确保用于执行这一调用的对象不是null。  
7．[位置]：140页倒数9行。
[类型]：翻译错误。
[译文原文]：“而且组件对于不同的时间进度表其版本也不同。”
[英文原文]：“and components tend to version with different schedules”
[建议译文]：而且这些组件的版本发布一般都基于不同的日程安排。  
8．[位置]：141页3行。
[类型]：翻译错误。
[译文原文]：“如果类最初是密封的，将来就无需破坏兼容性将类改变成非密封的。
[英文原文]：“When a class is originally sealed, it can change to unsealed in the future without breaking compatibility.”
[建议译文]：如果类原来是密封的，将来把它改为非密封的并不会破坏兼容性。  ----- 《CLR via C#》中文版民间勘误（三） ----- 9．[位置]：141页5行。
[类型]：翻译错误。
[译文原文]：“另外，如果非密封的类定义了非密封的虚方法，那就必须在新版本的类中保存虚方法的自定义调用，否则将来可能会破坏派生类的兼容性。
[英文原文]：“In addition, if the unsealed class defines any unsealed virtual methods, ordering of the virtual method calls must be maintained with new versions or there is the potential of breaking derived types in the future.”
[评论]：“在新版本的类中保存虚方法的自定义调用”是什么意思，原文中有这样的意思吗？能否请译者出来解释一下？这句话中“ordering”一词令人费解，我也说不准它倒底是什么意思。请各位指教。  
10．[位置]：141页9行。
[类型]：翻译错误。
[译文原文]：“但是，如果JIT编译器通过使用密封类将调用看成虚方法，……”
[英文原文]：“However, if the JIT compiler sees a call to a virtual method using a sealed type, …”
[建议译文]：但是，如果看到一个使用密封类型对虚方法的调用……  
11．[位置]：141页倒数2行。
[类型]：翻译错误。
[译文原文]：“这将允许基类改变它不影响派生类的观点。”
[英文原文]：“This would allow the base class to change with the knowledge that it will not impact a derived class.”
[建议译文]：这样一来，因为知道不会影响到派生类，所以可以放心地对基类进行修改。   
12．[位置]：150页倒数17行。
[类型]：翻译错误。
[译文原文]：“当某个字段是引用类型，并且该字段标记为readonly时，它就是不可改变的引用，而不是字段所引用的对象。”
[英文原文]：“When a field is of a reference type and the field is marked as readonly, it is the reference that is immutable, not the object that the field refers to.”
[建议译文]：如果一个字段属于引用类型，并且被标记为readonly时，不可改变的是这个引用本身，而不是它所引用的对象。   ----- 《CLR via C#》中文版民间勘误（四） ----- 13．[位置]：174页第8章第8节第一行。
[类型]：翻译错误。
[译文原文]：声明方法的参数类型时，应尽可能地指定最弱的类型，并且最好在基类上定义接口。
[英文原文]：“When declaring a method's parameter types, you should specify the weakest type possible, preferring interfaces over base classes.”
[评论]：“最好在基类上定义接口”这句话倒底是什么意思？“preferring interfaces over base classes”这句话的确令人费解。从后文来看，我怀疑此处是作者的笔误，把“and”写成“over”了。这一点欢迎大家指教。
[建议译文]：声明方法的参数类型时，应指定尽可能弱的类型，接口比基类更好。 说明：基本同意修改为：当声明方法的参数类型时，应尽可能地指定最弱的类型，最好是接口类型，而不是基类类型。  14．[位置]：174页倒数7行。
[类型]：翻译不当。
[译文原文]：“从反面（flip side）来讲，通常情况下，最好尽量将方法的返回类型声明为最强的类型（尽量不要限于一个具体的类型）”。
[英文原文]：“On the flip side, it is usually best to declare a method's return type by using the strongest type possible (trying not to commit yourself to a specific type).”
[评论]：“尽量不要限于一个具体的类型”这种译法在此场合让人越看越不明白。揣摩作才的本意，括号里的话应该是从方法的调用者的角度来说的，意思是指如果把方法的返回类型指定为弱类型，那么对于调用者来说，使用这个返回值的时候就受到很大限制，就象是把话说满了，以后想改都不行了。这样理解的话，翻译的时候就应该适量加入一些内容。当然，这种理解只是我个人的看法，欢迎大家指教。
[建议译文]：另一方面，方法的返回类型一般应该声明为尽量强的类型（以免在调用代码中使用方法的返回值时被局限于一个特定的类型）。 说明：不接受，但可以参考，如果觉得不太好理解的话，或者怕引起误解的话，可以加入一个译注。但是这句话从上下文中可以理解出，后面有解释语句。修改为：另一方面，通常情况下，最好尽量将方法的返回类型声明为最强的类型（尽量不要局限于一个特定的类型）。（译注：以免在调用代码中使用方法的返回值时局限于一个特定的类型，从而失去灵活性。） 15．[位置]：178页倒数19行。
[类型]：翻译不当。
[译文原文]：“属性不能被重载，也就是说，如果其类型不同，两个属性可以同名。”
[英文原文]：“It isn't possible to overload properties(that is, have two properties with the same name if their types are different).”
[建议译文]：属性不能重载，也即，不能定义两个类型不同而名称却相同的属性。 说明：不同意，最终意思虽然相同，但是强调的重点不一样了。 16．[位置]：178页倒数16行。
[类型]：翻译不当。
[译文原文]：“通过属性的get和set方法操作类型内定义的私有字段，这种做法也十分常见。私有字段通常称为后备字段（backing field），但是get和set方法没有必要访问后备字段。”
[英文原文]：“It's also quite common for the property's get/set methods to manipulate a private field defined within the type. This field is commonly referred to as the backing field. The get and set methods don't have to access a backing field, however.”
[建议译文]：通过属性的get和set方法操作类型内定义的私有字段，这种做法也十分常见。该私有字段通常称为后台字段（backing field）。但是，get和set方法也并不是非得访问一个后台字段不可。 说明：给出的[译文原文]与交稿内容不符。原译文：通过属性的get和set方法操作类型内定义的私有字段的做法也十分常见。私有字段通常作为后备字段（backing field）引用，但是get和set方法并非必须要访问后备字段。 ----- 《CLR via C#》中文版民间勘误（五） ----- 17．[位置]：182页14行。
[类型]：翻译错误。
[译文原文]：“创建一个索引器然后在相关的数组中查询数值的做法十分常见。”
[英文原文]：“It's quite common to create an indexer to look up values in an associative array.”
[评论]：“associative array”是一个术语。普通数组是通过一个整型的索引值来定位元素，而关联数组则可通过字符串等其它类型的索引值来定位元素。
[建议译文]：创建一个索引器来在关联数组中查找值的做法很常见。 说明：接受 18．[位置]：217页第11章第3节第4段。
[类型]：翻译不当。
[译文原文]：“StringBuilder的String方法返回的String绝对不能更改。所以，如果调用一个方法来修改StringBuilder维护的字符串字段，StringBuilder的方法就会收到信息，知道已在字符串字段上调用了ToString，所以会在内部创建并使用一个新的字符数组，让你对这个新的数组执行操作，而不影响之前的ToString调用返回的字符串”。
[英文原文]：“The String returned from StringBuilder's ToString method must not be changed. So if you ever call a method that attempts to modify the string field maintained by the StringBuilder, the StringBuilder's methods will have the information that ToString was called on the string field and they will internally create and use a new character array, allowing you to perform manipulations without affecting the string returned by the previous call to ToString.”
[评论]：我认为作者本人的表达就有些不清楚（包括一些语法问题）。这种情况下，翻译如果强调绝对忠实于原文，恐怕反不利于读者的理解。作者第一句话中所说的“更改”，是指因调用StringBuilder的方法而对（先前调用它的ToString方法得到的）字符串的更改，而不是调用Sting类的方法而对（先前调用StringBuilder的ToString方法得到的）字符串的更改。假如是后者，因为String类的方法本来就不会在原字符串身上进行更改，而是会把更改结果作为一个新字符串返回，所以这样说毫无意义，作者不可能是这种意思。同样的道理，作者在第二句话中所说的“方法”也应该是StringBuilder类的方法而不是String类的方法。因此，作者在这一段的本意，应该是说：在对StringBuilder类实例调用过ToString方法得到一个字符串（后称s）之后，再调用StringBuilder类的一些会导致其内部维护的字符串发生改变的方法的话，这个改变不会体现在s身上。基于这样的认识，翻译的时候必须补充一些内容。当然，这个问题也欢迎大家指教。
[建议译文]：StringBuilder的ToString方法返回的字符串不能被（StringBuilder的方法）更改。如果在调用过ToString方法后，再调用StringBuilder的会修改其维护的字符串字段的方法，那么方法会知道之前ToString已经被调用过，因此它将在内部另建并使用一个新的字符数组，这使你能够修改StringBuilder维护的字符串，同时又不影响先前调用ToString时返回的字符串。  ----- 《CLR via C#》中文版民间勘误（六） ----- 19．[位置]：257页代码中的Unsafe2DimArrayAccess方法。
[类型]：原著错误。
[说明]：“Int32 dim0Elements = dim0HighIndex – dim0LowIndex;”这句应该改成
“Int32 dim1Elements = dim1HighIndex – dim1LowIndex + 1;”。
“Int32 baseOfDim = x * dim0Elements;”这句应该改成
“Int32 baseOfDim = x * dim1Elements;”。因为从baseOfDim的用途来看，其中原来的“dim0Elements”应该是指第二维的元素个数，因此在前后两句中都应该把其名字中的“0”改为“1”。至于第一句中应该再加上一个数值1的原因，就不必多说了吧。这个错误在作者本人提供的勘误中都还没有指出来。   20．[位置]：273页7行。
[类型]：翻译不当。
[译文原文]：“在.NET Framework参考文档中查看一个类型的方法时，列出的是显式接口的方法实现，但没有类型的具体帮助，只能看到接口方法的常规帮助。”
[英文原文]：“When examining the methods for a type in the .NET Framework reference documentation, explicit interface method implementations are listed, but no type-specific help exists; you can just read the general help about the interface methods.”
[建议译文]：在.NET Framework参考文档中查看一个类型的方法时，显式接口方法实现也会列出来，但是没有特定于该类型的（针对显式接口方法实现的）帮助信息，只能读到关于那些接口方法的一般性帮助信息。  21．[位置]：275页倒19行。
[类型]：翻译错误。
[译文原文]：“通过为基类型提供一个良好的默认实现，然后开始使用能正常工作并通过良好测试一个类型，以后就可以对需要它的地方做出修改。”
[英文原文]：“By providing a base type with a good default implementation, you start off using a type that works and is well tested; you can then modify parts that need modification.”
[评论]：这个错误实在莫名其妙，就算用翻译软件来译也不该出现这样古怪的译法吧。
[建议译文]：通过提供一个具有良好的默认实现的基类，即可用上一个管用的并且已经认真测试过的类型，然后，你可以对需要修改的部分进行修改。  22．[位置]：288页17行。
[类型]：翻译错误。
[译文原文]：“但本来应该像下面这样定义Feedback委托：”
[英文原文]：“However, I could have defined my Feedback delegate as follows:”
[建议译文]：但我本来也可以这样定义Feedback委托   ----- 《CLR via C#》中文版民间勘误（七） ----- 23．[位置]：316页倒数第1段（不计代码）第3行。
[类型]：疑似印刷错误。
[译文原文]：“CLR允许基于类型参数名称或者约束来进行重载。”
[英文原文]：“The CLR doesn't allow overloading based on type parameter names or constraints”
[建议译文]：把“允许”改成“不允许”。   24．[位置]：317页倒数12行。
[类型]：翻译错误。
[译文原文]：“不需要指定以下特殊的引用类型：”
[英文原文]：“You cannot specify one of the following special reference types:”
[建议译文]：不能指定下列特殊引用类型。  25．[位置]：318页16行
[类型]：翻译错误。
[译文原文]：“然而，编译器和CLR将任何System.Nullable值类型视为一个特殊类型，而可空的类型不能指定这个约束。”
[英文原文]：“However, the compiler and the CLR treat any System.Nullable value type as a special type, and nullable types do not satisfy this constraint.”
[建议译文]：然而，编译器和CLR把所有System.Nullable值类型作为特殊类型对待，所以可空类型不能满足这一（struct）约束。   26．[位置]：330页7行。
[类型]：翻译错误。
[译文原文]：“除此之外，可以使用一个基于零的一维数组，并选择性地将上述类型添加到其中。”
[英文原文]：“In addition, you can use a single dimensional, zero-based array of any of these types.”
[建议译文]：此外，也可使用元素为这些类型的一维零基数组。   ----- 《CLR via C#》中文版民间勘误（八） ----- 27．[位置]：337页14行。
[类型]：翻译错误。
[译文原文]：“通常，我们可以使用CustomAttributeData类，分析通过Assembly的静态方法ReflectionOnlyLoad（也在第22章讨论）在一个程序集的元数据中加载的属性。”
[英文原文]：“Typically, you'll use the CustomAttributeData class to analyze attributes in metadata for an assembly that is loaded via Assembly's static ReflectionOnlyLoad method(also discussed in Chapter 22).”
[评论]：attribute是通过Assembly.ReflectionOnlyLoad加载到一个程序集的元数据当中去的吗？译者这个错误也犯得太业余了一点吧。
[建议译文]：CustomAttributeData类的典型用法是用于分析一个用Assembly的静态ReflectionOnlyLoad方法（也在第22章讨论）加载的程序集的元数据中的属性。  28．[位置]：337页19行。
[类型]：翻译错误。
[译文原文]：“调用它时，它会返回Ilist类型的一个对象中，返回由CustomAttributeData对象构成的一个集合。”
[英文原文]：“when you call it, it returns a collection of CustomAttributeData objects in an object of type IList”
[建议译文]：调用它时，将返回一个Ilist类型的对象，其中包含了一批CustomAttributeData类型的对象。   29．[位置]：344页倒数3行。
[类型]：翻译错误。
[译文原文]：“但并不是一个理想的结果，因为方法现在是作为一个非空的值传递的，即使Nullable变量逻辑上包含null值。”
[英文原文]：“This is not ideal because the method is now being passed a non-null value even though the Nullable variable logically contained the value of null.”
[建议译文]：这种处理并不理想，因为尽管那个Nullable变量逻辑上包含着null值，现在传给方法的却是一个非空值。  30．[位置]：355页倒数8行。
[类型]：翻译错误。
[译文原文]：“所有未抛出的异常将被封装入一个System.Runtime.CompilerServices.RuntimeWrappedException。”
[英文原文]：“All non-exceptions thrown will be wrapped in a System.Runtime.CompilerServices.RuntimeWrappedException.”
[建议译文]：抛出的各类“非异常”（non-exception，指一个并非exception类或其派生类实例的对象）都会用一个System.Runtime.CompilerServices.RuntimeWrappedException类型对象加以包装。 说明：上交译文中本句没有翻译，保留的是英文原文----- 《CLR via C#》中文版民间勘误（九） ----- 31．[位置]：355页倒数2行。
[类型]：翻译错误。
[译文原文]：“相反，CLR不包装不符合CLS的对象，而且仅当catch块没有指定任何类型时才调用我们自己的代码。”
[英文原文]：“And instead, the CLR should unwrap the non-CLS-compliant object and call your code only if you have a catch block that doesn't specify any type at all.”
[建议译文]：作为替代措施，仅当存在一个根本未指定任何类型的catch块时，CLR才应该解开对那个非CLS兼容的对象的包装并调用你的代码。 说明：接受修改为：作为替代措施，仅当存在一个根本未指定任何类型的catch块时，CLR才会解开不符合CLS的对象并调用代码。 32．[位置]：365页倒数16行。
[类型]：翻译不当。
[译文原文]：“记住，Debug.Assert的调用在程序集的发行版本中不存在，但是异常仍然被抛出……程序集不应使用Debug.Assert调用来确保另一程序集中的代码正确调用方法，但异常可以这样使用。”
[英文原文]：“Remember that Debug.Assert calls vanish out of the code for a release build, whereas exceptions will still get thrown … an assembly should not use Debug.Assert calls to ensure that code in another assembly is calling a method correctly; use exceptions for this.”
[建议译文]：记住，在程序集的release生成版本的代码中不会再有对Debug.Assert的调用，但依然会有异常被抛出……程序集如要确保一个方法能被另一程序集的代码正确地调用，应该使用异常，而不是Debug.Assert调用。 说明：接受修改为：记住，Debug.Assert的调用在程序集的发行版本代码中已不存在，但是异常仍然被抛出……程序集不应再使用Debug.Assert调用来确保另一程序集中的代码正确调用方法，而应该使用异常。 33．[位置]：371页2行。
[类型]：翻译错误。
[译文原文]：“在进入该公共方法后，代码首先要检查x是否为0，如果x为0，方法就抛出一个ArgumentOutOfRangeException异常。每次执行方法时都要进行一次这样的检查，”
[英文原文]：“Upon entry into this public method, code could check to see whether x is 0, and if it is, throw an ArgumentOutOfRangeException exception. This check would be performed every time,”
[评论]：虚拟语气没有译出来。
[建议译文]：本来也可以在该公共方法的入口处让代码检查x是否为0，并在其为0的情况抛出一个ArgumentOutOfRangeException异常。这样一来，检查会在每次调用方法时都被执行。 说明：接受 34．[位置]：371页18行。[类型]：翻译错误。
[译文原文]：“我们应该为调用堆栈中居于较高层次的代码提供机会，使它们不仅能够捕获System.Exception异常，而且还能够捕获其他一些用作基础类型的较具体的异常。”
[英文原文]：“Give the code higher up the call stack a chance to catch System.Exception or some other exception that's a base type for more specific exceptions.”
[建议译文]：把捕获System.Exception或别的身为那些更具体的异常的基类型的异常的机会让给调用堆栈中更高层的代码吧。 说明：基本接受，但感觉有些生硬修改为：我们应该为调用堆栈中居于较高层次的代码提供机会，使它们能够捕获System.Exception异常，或者其他一些用作较具体的异常的基础类型的异常。 ----- 《CLR via C#》中文版民间勘误（十） ----- 35．[位置]：374页2行。
[类型]：翻译错误。
[译文原文]：“需要特别指出的是：TryXxx方法的Boolean类型的值返回false时表示仅有一个类型转换失败。但是方法仍抛出其他类型失败的异常。例如，对于Int32的TryParse方法，如果它的参数无效，它就抛出一个ArgumentException异常，”
[英文原文]：“One thing I want to make absolutely clear: A TryXxx method's Boolean return value returns false to indicate one and only one type of failure. The method should still throw exceptions for any other type of failure. For example, Int32's TryParse throws an ArgumentException if the styles argument is not valid,”
[建议译文]：需要特别指出的是：TryXxx方法的Boolean型返回值为false代表着一种、而且仅仅是一种类型的故障。方法在遇到其它类型的故障时依然会抛出异常。例如，Int32的TryParse方法当styles参数无效时将抛出一个ArgumentException异常。 说明：接受  36．[位置]：377页7行。
[类型]：翻译错误。
[译文原文]：“该功能不太友好，因为它使应用程序在字段中失败时的调试工作异常困难。”
[英文原文]：“This is unfortunate because it makes debugging applications that have failed in the field much more difficult.”
[评论]：不要一见“field”就译“字段”！
[建议译文]：这之所以令人遗憾，是因为它使实地调试发生故障的应用程序的工作变得更加困难。说明：接受 37．[位置]：389页倒数3行。
[类型]：翻译错误。
[译文原文]：“我是这样认为的：任何实现了Finalize方法的类型实际上在它的对象被删除之前声明它拥有这些资源。”
[英文原文]：“I think of it this way: any type that implements the Finalize method is in effect stating that all of its objects want a last meal before they are killed.”
[评论]：这个暗喻的意思很明显，不必译出其隐含的意思。就算要译出其隐含意思，那也不是译者所理解的这个意思。
[建议译文]：我是这样想象的，任何实现Finalize方法的类型实际上是在声称：所有它的对象在被处决之前都想最后再吃上一顿饭。 说明：不同意，个人认为还是意译好，如同谚语一样，直译的意思不如意译好理解。 38．[位置]：390页11行。
[类型]：印刷错误。
[译文原文]：“而对base.Finalize的调用则在block块中生成。”
[英文原文]：“and that a call to base.Finalize is emitted into a finally block.”
[评论]：“block”应该改为“finally”。另外，A在B中生成这种说法感觉有点问题，但好歹大家都明白其意思，也勉强使得。 说明：接受----- 《CLR via C#》中文版民间勘误（十一） ----- 39．[位置]：391页3行。
[类型]：翻译错误。
[译文原文]：“在对象之上编译这些方法可以确保一点：”
[英文原文]：“Compiling these methods upon object construction guarantees that …”
[评论]：我怀疑译者是不是有阅读障碍。
[建议译文]：在构造对象时就编译这些方法确保了…… 说明：接受 40．[位置]：391页倒数13行（代码的注释）。
[类型]：翻译错误。
[译文原文]：“如果ownHandle为true，那么当这个派生自SafeHandle的对象被收集时，本地资源就是关闭的。”
[英文原文]：“If ownsHandle is true, then the native resource is closed when this SafeHandle-derived object is collected.”
[建议译文]：“如果ownHandle为true，那么当这个派生自SafeHandle的对象被收集时，本地资源将被关闭。” 说明：不同意，没有将来时的含义。 41．[位置]：392页6行。
[类型]：翻译错误。
[译文原文]：“不采用ReleaseHandlerFailed的托管调试助手（MDA）”
[英文原文]：“Fire the ReleaseHandleFailed Managed Debugging Assistant (MDA)”
[评论]：看起来译者似乎把“fire”理解成“解雇”了。
[建议译文]：激活ReleaseHandleFailed托管调试助手（MDA）。 说明：接受 42．[位置]：394页倒数19行。
[类型]：翻译错误。
[译文原文]：“从而自动地构建一个SafeWaitHandle类的实例，并传递到CreateEvent函数返回的句柄值中。”
[英文原文]：“causing the CLR to automatically construct an instance of the SafeWaitHandle class, passing in the handle value returned from CreateEvent”
[建议译文]：“从而自动构建一个SafeWaitHandle类的实例，在此过程中将从CreateEvent函数返回的句柄值传递给它。” 说明：接受，但与原文不太符修改为：将导致CLR自动地构建一个SafeWaitHandle类的实例，并将从CreateEvent函数返回的句柄值传递给它。----- 《CLR via C#》中文版民间勘误（十二） ----- 43．[位置]：395页2行。
[类型]：翻译错误。
[译文原文]：“如果编写或者调用代码操作IntPtr类型的句柄，就可以不用SafeHandle对象来访问句柄……”
[英文原文]：“If you are writing or calling code to manipulate a handle as an IntPtr, you can access it out of a SafeHandle object …”
[建议译文]：如果你编写的代码或调用的代码需要以IntPtr的形式来操作句柄，你可以从一个SafeHandle类型的对象中获取它…… 说明：接受修改为：如果编写的代码或调用的代码需要以IntPtr的形式来操作句柄，则可以从一个SafeHandle对象中获取它…… 44．[位置]：397页13行。
[类型]：翻译错误。
[译文原文]：“但是，在访问值类型实例或者引用类型对象时不定义Finalize方法将相当好。”
[英文原文]：“However, it is perfectly OK to access value type instances or reference type objects that do not define a Finalize method.”
[评论]：难以理解何以发生这样的错误。
[建议译文]：但是，访问值类型的实例或未定义Finalize方法的引用类型的对象则是完全可以的。 说明：接受，that是不是修饰前面的value type instances和 reference type objects两部分修改为：但是，访问未定义Finalize方法的值类型实例或引用类型对象时则是完全可以的。 45．[位置]：397页倒数20行。
[类型]：翻译错误。
[译文原文]：“Finalize方法在垃圾收集结束时被调用，有5种事件会导致一个对象的Finalize方法被调用：”
[英文原文]：“Finalize methods are called at the completion of a garbage collection, which is started by one of the following five events:”
[建议译文]：下列五种事件会启动垃圾收集，收集结束时会调用Finalize方法： 说明：接受修改为：Finalize方法在垃圾收集结束时被调用，下列5种事件会导致垃圾收集的启动： 46．[位置]：399页倒数13行。
[类型]：翻译错误。
[译文原文]：“在终结可达队列中出现的指针标识该对象的Finalize方法即将被调用。”
[英文原文]：“Each pointer in the freachable queue identifies an object that is ready to have its Finalize method called.”
[建议译文]：终结可达队列中的每一个指针标识着一个其Finalize方法即将被调用的对象。 说明：接受修改为：终结可达队列中的每一个指针都标识着一个其Finalize方法即将被调用的对象。----- 《CLR via C#》中文版民间勘误（十三） ----- 47．[位置]：399页倒数3行。
[类型]：翻译错误。
[译文原文]：“我们不应该执行对正在执行代码的线程做任何假设的Finalize方法中的任何代码。”
[英文原文]：“you shouldn't execute any code in a Finalize method that makes any assumptions about the thread that's executing the code”
[建议译文]：你不应该在Finalize方法中执行任何对其执行线程有所假设的代码。 说明：接受修改为：我们不应该在Finalize方法中执行任何对执行代码的线程有任何假设的代码。 48．[位置]：408页倒数16行。
[类型]：翻译不当。
[译文原文]：“Mutex类确实实现了IDisposable接口，但是在释放本地资源时调用了Dispose方法，并且Mutex类不对锁本身做任何处理。”
[英文原文]：“The Mutex class does implement the IDisposable interface, but calling Dispose on it releases the native resource; it has nothing to do with the lock itself.”
[建议译文]：Mutex类的确实现了Idisposable接口，但是对其Dispose方法的调用只是释放本地资源，这与锁本身没什么关系。 说明：接受 49．[位置]：410页倒数11行。
[类型]：翻译错误。
[译文原文]：“.NET Framework 2.0提供了一个称为托管调试助手（MDA）的辅助调试应用程序。启用MDA后，.NET Framework查找公共的编程错误，并且启动一个相应的MDA。在调试器中，MDA就像抛出一个异常。检测到StreamWriter对象在被垃圾收集之前没有显式地进行关闭时，就会出现一个可以利用的MDA。为了在Visual Studio中启用MDA……”
[英文原文]：“Version 2.0 of the .NET Framework offers a feature called Managed Debugging Assistants (MDA).When an MDA is enabled, the .NET Framework looks for certain common programmer errors and fires a corresponding MDA. In the debugger, it looks like an exception has been thrown. There is an MDA available to detect when a StreamWriter object is garbage collected without having prior been explicitly closed. To enable this MDA in Visual Studio,”
[评论]：大面积的错误。
[建议译文]：.NET框架的2.0版本提供了一个名为托管调试助手（MDA）的特性。启用一个MDA后，.NET框架就会查找特定种类的常见的编程错误，并为其激活相应的MDA。这在调试器中看起来仿佛是有一个异常被抛出一样。有一个MDA就是用于探测StreamWriter对象未曾被显式关闭过就被作为垃圾收集这种情况的。为了在Visual Studio中启用这个MDA…… 说明：接受  50．[位置]：412页16行。
[类型]：翻译错误。
[译文原文]：“我们可以以GCHandle实例作为参数调用Free方法（该方法通过将IntPtr字段设为0也会使实例无效）。”
[英文原文]：“you take the GCHandle instance and call the Free method (which also invalidates the instance by setting the IntPtr field to zero).”
[建议译文]：你使用该GCHandler实例调用Free方法（它也会通过将IntPtr字段设置为0来使该实例无效）。 说明：接受修改为：我们可以使用GCHandle实例调用Free方法（它通过将IntPtr字段设为0也会使实例无效）----- 《CLR via C#》中文版民间勘误（十四） -----51．[位置]：414页4行。
[类型]：翻译错误。
[译文原文]：“MailManager对象将返回的GCHandler实例保存在一个垃圾收集中（而不是保存委托对象的引用）。”
[英文原文]：“The MailManager object will save the returned GCHandle instance in a collection instead of saving the reference to the delegate object.”
[建议译文]：MailManager对象在一个集合中保存所返回的GCHandle实例，而不是保存对该委托对象的引用。 说明：接受 52．[位置]：414页倒数13行。
[类型]： 翻译错误。
[译文原文]：“WeakReference类底部的对象也称为类。”
[英文原文]：“The downside of the WeakReference class is that it is a class.”
[评论]：太荒唐了！我们的译者太有才了！
[建议译文]：WeakReference类的缺点在于它是一个类。 说明：接受 53．[位置]：416页倒数6行。
[类型]：翻译错误。
[译文原文]：“当内存充满或者接近充满时，垃圾收集不会发生。相反，无论何时，只要第0代充满，垃圾收集操作就会发生，”
[英文原文]：“Garbage collections do not occur when memory is full or close to full. Instead, garbage collections occur whenever generation 0 is full,”
[建议译文]：垃圾收集不是发生在内存占满或即将占满时，而是每当第0代占满时就发生。 说明：接受 54．[位置]：417页倒数19行。
[类型]：翻译错误。
[译文原文]：“但是，如以下代码所示，如果Finalize方法执行的代码中放了一个指向静态字段中的对象的指针，情况又会怎么样呢？”
[英文原文]：“But what if an object's Finalize method executed code that placed a pointer to the object in a static field, as demonstrated in the following code?”
[建议译文]：但是，如果对象的Finalize方法执行的代码，如下所示，把一个指向该对象的指针存入一个静态字段中，那又该如何呢？ 说明：接受----- 《CLR via C#》中文版民间勘误（十五） ----- 55．[位置]：418页倒数17行。
[类型]：翻译错误。
[译文原文]：“更常见的做法是在Finalize方法内部设置一个根来引用对象从而使对象复苏。”
[英文原文]：“It's far more common to conditionally set a root to reference the object inside the Finalize method.”
[建议译文]：更常见的做法是在Finalize方法中条件性地让一个根引用对象。 说明：接受 56．[位置]：422页11行。
[类型]：翻译不当。
[译文原文]：“在那些线程在其堆栈顶部大部分时间都空闲的应用程序中垃圾收集器的工作情况相当出色。”
[英文原文]：“The garbage collector works extremely well for applications with threads that sit idle at the top of their stack most of the time.”
[建议译文]：有些应用程序，其线程大部分时间都无所事事，它们的堆栈因此大部分时间都处在顶部位置（栈中空空如已）。对于这类程序，垃圾收集器工作得尤其出色。 说明：接受 57．[位置]：422页倒数15行。
[类型]：翻译不当。
[译文原文]：“实际上，大多数应用程序的根生存在参数或者局部变量的线程的堆栈中。”
[英文原文]：“In fact, most of an application's roots live on the thread's stack in arguments or local variables.”
[建议译文]：实际上，应用程序的大多数根都以参数或局部变量的形式存在于线程的堆栈上。 说明：接受 58．[位置]：440页倒数6行。
[类型]：翻译错误。
[译文原文]：“然而，共享这些资源的收益没有与投入成正比。”
[英文原文]：“Unfortunately, the benefit gained by sharing these resources does come with a price”
[建议译文]：可惜共享这些资源所带来的好处是有代价的。 说明：接受----- 《CLR via C#》中文版民间勘误（十六） ----- 59．[位置]：446页倒数8行。
[类型]：翻译错误。
[译文原文]：“在任意时刻，一个应用程序域只能执行一个线程。”
[英文原文]：“at any given time, a thread is considered to be in just one AppDomain.”
[建议译文]：在任一给定时刻，一个线程只能运行在一个应用程序域之中。 说明：接受 60．[位置]：447页倒数4行。
[类型]：翻译错误。
[译文原文]：“因为CLR实际上要结束调用方法来执行字段的访问。”
[英文原文]：“because the CLR really ends up calling methods to perform the field access”
[建议译文]：因为CLR实际上最终要通过调用方法来执行字段访问。 说明：接受 61．[位置]：451页5行。
[类型]：翻译错误。
[译文原文]：“无论何时，只要代码调用AppDomain.Unload方法，被卸载应用程序域中就没有任何线程，因此，CLR不必抛出ThreadAbortException异常。”
[英文原文]：“Whenever my code calls AppDomain.Unload, there are no threads in the unloading AppDomain, and therefore, the CLR doesn't have to throw any ThreadAbortException exceptions.”
[建议译文]：我的代码中，在调用AppDomain.Unload的时候，所卸载的AppDomain中都没有线程在运行，所以CLR也就用不着抛出ThreadAbortException异常。 说明：不同意，这里强调的是Whenever，而不是my 62．[位置]：466页1行。
[类型]：翻译不当。
[译文原文]：“我们可以为GetType方法传递一个合乎程序集类型条件（assembly-qualified type）的字符串，例如……。”
[英文原文]：“You can pass an assembly-qualified type string, such as "System.Int32, mscorlib, Version= 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", to GetType.”
[评论]：“合乎程序集类型条件的字符串”这种译法不妥，让人看得莫明其妙。“qualified”在这种场合的含义是“restricted”或“modified”。国内技术图书通常把这种用法的“qualified”译为“限定”。比如“full-qualified name”一般译为“完全限定名”。
[建议译文]：可以传给GetType方法一个程序集限定的类型字符串，比如…… 说明：接受----- 《CLR via C#》中文版民间勘误（十七） ----- 63．[位置]：469页13行。
[类型]：翻译错误。
[译文原文]：“ObjectHandle类型允许我们在一个应用程序域中创建一个对象，然后将其传递到其他的应用程序域中，但不能强制对象进行具体化（materialize）。准备具体化该对象时，可以调用ObjectHandle的Unwrap方法。该方法加载在调用Unwrap方法的应用程序域中定义的被具体化的类型的程序集。”
[英文原文]：“An ObjectHandle is a type that allows an object created in one AppDomain to be passed around to other AppDomains without forcing the object to materialize. When you're ready to materialize the object, you call ObjectHandle's Unwrap method. This method loads the assembly that defines the type being materialized in the AppDomain where Unwrap is called.”
[建议译文]：ObjectHandle类型允许将一个应用程序域中创建的对象传递到其它应用程序域，而且在此过程中不必将该对象具体化。准备具体化该对象时，调用ObjectHandle的Unwrap方法即可。该方法在调用Unwrap的应用程序域中加载定义了所要具体化的类型的程序集。 说明：接受 64．[位置]：471页倒数20行。
[类型]：翻译不当。
[译文原文]：“插件开发人员可以按他们的愿望设计一个新版本的程序集，而宿主应用程序无论怎样使用插件类型，也都不会出现任何问题。”
[英文原文]：“The add-in developers are able to put out a new version of their assembly as often as they'd like, and the host application will be able to consume the add-in types without any problem whatsoever.”
[建议译文]：插件开发者可以按自己的频度发布其程序集的新版本，宿主应用程序不会因此而在使用这些插件方面出现任何问题。 说明：基本同意修改为：插件开发人员可以按他们的意愿发布新版本的程序集，而宿主应用程序在使用这些插件时不会因此而出现问题。 65．[位置]：471页倒数11行。
[类型]：翻译错误。
[译文原文]：“需要花费一些时间，通过将跨程序集边界通信所用的类型隔离，在程序集中设计一个结构清晰的类型。”
[英文原文]：“Take your time to architect this cleanly by isolating the types that you use for communication across assembly boundaries into their own assembly.”
[建议译文]：花点时间，通过将用于跨程序集边界通信的类型隔离到它们自己的程序集之中，以获得一个清晰的架构。 说明：接受  66．[位置]：478页6行（不计表格）。
[类型]：翻译错误。
[译文原文]：“只有设置BindingFlags的IgnoreCase，这些方法才有用武之地。”
[英文原文]：“This is when BindingFlags's IgnoreCase flag comes in handy.”
[建议译文]：BindingFlags的IgnoreCase标志在此可以派上用场。 说明：接受----- 《CLR via C#》中文版民间勘误（十八） ----- 67．[位置]：497页4行。
[类型]：翻译错误。
[译文原文]：“为了让线程继续运行，线程可以在线程池的队列中加入一个工作项，让线程池中的线程来执行打开文件的代码。当然，这必须在拥有合适许可权限的程序集中进行。这种‘工作区’智取安全权限的现象可以允许怀恶意的代码对受限资源进行严重破坏。为了阻止这种获得安全权限的方式，……”
[英文原文]：“To work around this, the thread could queue a work item to the thread pool and have the thread pool thread execute code to open the file. Of course, this would have to be in an assembly that has the right permission. This "workaround" circumvents security and allows malicious code to wreak havoc with restricted resources. To prevent this security exploit, …”
[建议译文]：为了绕过这种限制，该线程可能会把一个工作项加入线程池的队列，让线程池中的线程执行打开文件的代码。当然，这得在拥有合适权限的程序集中进行。这种“绕行”规避了安全机制，让恶意代码得以对受限资源造成重大破坏。为了阻止这种瞒天过海的花招，…… 说明：接受 68．[位置]：513页倒数16行。
[类型]：翻译错误。
[译文原文]：“调用者在执行异步I/O操作时就可以使用这个IasyncResult对象了。”
[英文原文]：“The caller can now use this object as it would when performing an asynchronous I/O operation.”[建议译文]：调用者现在就可以按类似于执行异步I/O操作时所用的套路来使用这个对象了。 说明：接受 69．[位置]：524页10行。
[类型]：翻译不当。
[译文原文]：“另外，我们还可以将volatile关键字应用于引用类型以及任何只要枚举类型的基础类型是Byte，Sbyte，Int16，UInt16，Int32，UInt32，Single和Boolean的枚举字段。”
[英文原文]：“You can also apply the volatile keyword to reference types and any enum field as long as the enumerated type has an underlying type of Byte, SByte, Int16, UInt16, Int32, UInt32, Single, or Boolean.”
[建议译文]：volatile关键字还可以用于引用类型的字段，以及其基础类型为Byte、 Sbyte、 Int16、 UInt16、 Int32、 UInt32、 Single或Boolean的枚举类型的字段。 说明：另外，我们还可以将volatile关键字应用于引用类型的字段，以及任何只要基础类型是Byte、Sbyte、Int16、UInt16、Int32、UInt32、Single或Boolean的枚举类型的字段。 70．[位置]：526页中间部分的代码。
[类型]：翻译错误加印刷错误。
[评论]：1. 所有注释中的“自动执行”，其英文为“Atomically performs”，应该译为“原子性地执行”。2. Decrement方法的注释应该是“//原子性地执行（location--）”。3. Add方法的注释第一行应该是“//原子性地执行（location+=value）”；第二行原译“//说明：值可以是一个可进行减法算的负值”不正确，应该译为“//说明：value可以是负值，以实现减法运算”。 说明：基本同意，将3中说明译为：“/说明：value可以是负值，从而允许进行减法运算”----- 《CLR via C#》中文版民间勘误（十九） -----71．[位置]：528页15行。
[类型]：翻译不当。
[译文原文]：“所有的开发人员不得不在每个需要线程同步的方法中编写必须的代码以进入或者离开该字段。”
[英文原文]：“All the developer has to do is write code to enter and leave the field as necessary in each method that requires thread synchronization.”
[建议译文]：开发人员要做的只是在每一个需要线程同步的方法中按要求编写代码以进入和离开该字段。 说明：不同意修改为：“开发人员不得不要做的全部事情，就是在每个需要线程同步的方法中编写必要的代码以进入或者离开该字段。” 72．[位置]：535页5行。
[类型]：翻译错误。
[译文原文]：“Monitor类应该被设计为这样，即我们可以利用它构建一个Monitor类型的静态实例从而创建一个线程同步锁。而且静态方法应该是可以操作锁对象本身的实例方法，因此，我们就不必对Monitor的任何方法传递System.Object参数。这样会解决所有的问题，并为所有的开发人员简化编程模型。顺便说一下，前面的代码在同步静态方法上表现一般，如果要同步静态方法，只需将所有成员的修饰符改为static，之后代码就可以正常工作了。”
[英文原文]：“It should have been designed so that you construct an instance of the Monitor type to create a thread synchronization lock. Then, the static methods would have been instance methods that operate on the lock object itself, and therefore, you wouldn't need to pass a System.Object argument to any of Monitor's methods. This would have solved all of the problems and would have simplified the programming model for all developers. By the way, the code above is trivially modified to synchronize static methods; just change all of the members to static, and everything just works.”
[评论]：一连串似是而非的句子。不知道译者自己是否明白他要表达的意思（比如什么“静态实例”、“表现一般”之类）？反正我是看不懂。
[建议译文]：它的设计应该允许你构建一个Monitor类型的实例，以创建一个线程同步锁。这样的话，那些静态方法就应该改为对锁对象自身进行操作的实例方法，于是，你也不用再给Monitor类的任何方法传递一个System.Object参数了。这将会解决所有的问题，并为所有开发者简化编程模型。顺便提一句，前述代码稍做修改便可用于同步静态方法：只须把所有成员改为静态即可。 说明：基本接受修改为：Monitor类应该被设计为这样，即我们可以利用它构建一个Monitor类型的实例，从而创建一个线程同步锁。于是，这些静态方法将成为操作锁对象本身的实例方法，因此，我们就不必再对Monitor的任何方法传递一个System.Object参数。这样会解决所有的问题，并为所有的开发人员简化编程模型。顺便说一下，前面的代码稍做修改就可以同步静态方法：只需将所有成员的修饰符改为static，之后代码就可以正常工作。----- 《CLR via C#》中文版民间勘误（二十） ----- 73．[位置]：535页倒数7行。
[类型]：翻译错误。
[译文原文]：“该技术不著名是因为它不是那么有趣或者有用。说它著名是因为有许多资料描述它。”
[英文原文]：“This technique is not famous because it is particularly interesting or useful. It is famous because there has been much written about it.”
[建议译文]：这一技术之所以有名，并非因其特别有趣或有用，而是因为有很多关于它的文献资料。 说明：接受 74．[位置]：535页倒数2行。
[类型]：翻译错误。
[译文原文]：“最后结果是，Microsoft果断地在内存模型上达成一致，也即CLR将使用该技巧并对其明确存档。…… 因为CLR在采用的内存模型上达成了一致，所以双检锁技巧在CLR中就根本不再是一个问题了。”
[英文原文]：“The result is that Microsoft decisively arrived at the memory model that the CLR would use and clearly documented it for everyone. … Because of the arrived-at memory model employed by the CLR, the doublecheck locking technique is not a problem on the CLR at all.”
[建议译文]：Microsoft最终设计出那个CLR后来采用的内存模型，并且为其提供了清楚的文档说明。…… 因为CLR采用的这个内存模型的缘故，双检锁技术在CLR平台上根本不成其为一个问题。 说明：可以参考修改为：最后结果是，Microsoft果断决定采用CLR后来使用的内存模型，并且为它提供了明确的存档说明。…… 因为在CLR采用的内存模型达成了一致，所以双检锁技巧在CLR平台上应用就根本不再是一个问题。 75．[位置]：536页代码中s_lock字段上方的注释。
[类型]：翻译错误。
[译文原文]：“s_lock对象用来实现线程安全，在定义这个对象时我们假设创建单个对象比创建一个System.Object对象的开销要昂贵，并且还假设创建单个对象完全没有必要。否则，在类的构造器中创建单个对象就比较高效和简单了。”
[英文原文]：“s_lock is required for thread safety and having this object assumes that creating the singleton object is more expensive than creating a System.Object object and that creating the singleton object may not be necessary at all. Otherwise, it is more efficient and easier to just create the singleton object in a class constructor”
[建议译文]：s_lock用于实现线程安全。提供这个对象，是基于如下假设：首先，创建该单体对象的开销高于创建一个System.Object对象；第二，该单体对象也许根本没必要创建。若非如此，在类构造器中创建该单体对象会更有效和方便。 说明：接受修改为：s_lock对象用来实现线程安全，在提供这个对象时我们假设创建单个对象比创建一个System.Object对象的开销要昂贵，并且还假设创建单个对象也许根本就没有必要。否则，在类的构造器中创建单个对象就比较高效和简单了。----- 《CLR via C#》中文版民间勘误（二十一·完） ----- 76．[位置]：537页24行。
[类型]：翻译不当。
[译文原文]：“同样，创建单实例对象肯定比创建用于加锁的对象（以获得一些收益）的代价要高。”
[英文原文]：“Also, creating the singleton object must be far more expensive than creating the object you use for locking in order to gain any benefit.”
[建议译文]：此外，创建单体对象的开销必须是远高于创建用于加锁的对象，否则应用这种技术就没有多少收益可言。 说明：接受 77．[位置]：538页12行。
[类型]：翻译错误。
[译文原文]：“因此在使用ReaderWriterLock时，如果希望让写线程等待处理，就可以给予写线程更高的优先级（相较于读线程）。我们知道有一些人们准备使用ReaderWriterLock类，但是由于这个类采用了读线程比写线程较高优先级的策略，所以写线程有时会发生饥饿，不能及时完成任务。”
[英文原文]：“So when using a ReaderWriterLock, if you have writers waiting, you want to give them higher priority than the readers. I know several people who have tried to use the ReaderWriterLock, but due to its policy of favoring readers over writers, writers get starved for time and do not complete their work in a timely fashion.”
[建议译文]：所以在使用ReaderWriterLock的时候，如果有写线程处于等待状态，你会希望它们能得到高于读线程的优先级。我见过一些人使用ReaderWriterLock，由于该类厚读薄写的策略，写线程总处于时间饥渴状态并因此难以及时完成任务。 说明：接受修改为：因此在使用ReaderWriterLock时，如果有写线程等待处理，则会希望给予写线程相对于读线程较高的优先级。我们知道有一些人们准备使用ReaderWriterLock类，但是由于这个类采用了读线程比写线程较高优先级的策略，所以写线程有时会发生饥饿，不能及时完成任务。 78．[位置]：538页17行。
[类型]：翻译错误。
[译文原文]：“它使得下述情况非常普遍：……”
[英文原文]：“It is becoming much more commonplace for one thread to enter a lock and start an operation to access some data and then have another thread eventually complete the operation on the data and exit the lock.”
[建议译文]：这种情况正变得更普遍：…… 说明：不同意，上下文不连贯修改为：当前，下述情况正变得非常普遍：…… 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1633732