java谜题学习笔记

A．        Java 谜题 1—— 表达式谜题

1)        谜题1：奇数性——无论你何时使用到了取余操作符，都要考虑到操作数和结果的符号。

2)        谜题2：找零时刻——并不是所有的小数都可以用二进制浮点数来精确表示的。二进制浮点对于货币计算是非常不适合的，因为它不可能将0.1——或者10的其它任何次负幂——精确表示为一个长度有限的二进制小数
在需要精确答案的地方，要避免使用float和double；对于货币计算，要使用int、long或BigDecimal。对于语言设计者来说，应该考虑对小数运算提供语言支持。一种方式是提供对操作符重载的有限支持，以使得运算符可以被塑造为能够对数值引用类型起作用，例如BigDecimal。另一种方式是提供原始的小数类型，就像COBOL与PL/I所作的一样。

3)        谜题3：长整除——当你在操作很大的数字时，千万要提防溢出——它可是一个缄默杀手。即使用来保存结果的变量已显得足够大，也并不意味着要产生结果的计算具有正确的类型。当你拿不准时，就使用long运算来执行整个计算。

4)        谜题4：初级问题——在long型字面常量中，一定要用大写的L，千万不要用小写的l。
相类似的，要避免使用单独的一个l字母作为变量名。例如，我们很难通过观察下面的代码段来判断它到底是打印出列表l还是数字1。（System.out.println(1);）
小写字母l和数字1在大多数打字机字体中都是几乎一样的。为避免你的程序的读者对二者产生混淆，千万不要使用小写的l来作为long型字面常量的结尾或是作为变量名。Java从C编程语言中继承良多，包括long型字面常量的语法。也许当初允许用小写的l来编写long型字面常量本身就是一个错误。

5)        谜题5：十六进制的趣事——混合类型的计算可能会产生混淆，尤其是十六进制和八进制字面常量无需显式的减号符号就可以表示负的数值。为了避免这种窘境，通常最好是避免混合类型的计算。

6)        谜题6：多重转型——有一条很简单的规则能够描述从较窄的整型转换成较宽的整型时的符号扩展行为：如果最初的数值类型是有符号的，那么就执行符号扩展；如果它是char，那么不管它将要被转换成什么类型，都执行零扩展。因为byte是一个有符号的类型，所以在将byte数值-1转换成char时，会发生符号扩展。作为结果的char数值的16个位就都被置位了，因此它等于216-1，即65535。从char到int的转型也是一个拓宽原始类型转换，所以这条规则告诉我们，它将执行零扩展而不是符号扩展。作为结果的int数值也就成了65535，这正是程序打印出的结果。如果你通过观察不能确定程序将要做什么，那么它做的就很有可能不是你想要的。

7)        谜题7：互换内容——

8)        谜题8：Dos Equis——
○如果第二个和第三个操作数具有相同的类型，那么它就是条件表达式的类型。换句话说，你可以通过绕过混合类型的计算来避免大麻烦。
○如果一个操作数的类型是T，T表示byte、short或char，而另一个操作数是一个int类型的常量表达式，它的值是可以用类型T表示的，那么条件表达式的类型就是T。
○否则，将对操作数类型运用二进制数字提升，而条件表达式的类型就是第二个和第三个操作数被提升之后的类型。
通常最好是在条件表达式中使用类型相同的第二和第三操作数。否则，你和你的程序的读者必须要彻底理解这些表达式行为的复杂规范。

9)        谜题9：半斤——请不要将复合赋值操作符作用于byte、short或char类型的变量上。在将复合赋值操作符作用于int类型的变量上时，要确保表达式右侧不是long、float或double类型。在将复合赋值操作符作用于float类型的变量上时，要确保表达式右侧不是double类型。这些规则足以防止编译器产生危险的窄化转型。
复合赋值操作符会悄悄地产生一个转型。如果计算结果的类型宽于变量的类型，那么所产生的转型就是一个危险的窄化转型。这样的转型可能会悄悄地丢弃掉精度或数量值。

10)     谜题10：八两——

B．        Java谜题2——字符谜题

11)     谜题11：最后的笑声——站在语言的立场上，若干个char和字符串的相似之处是虚幻的。语言所关心的是，char是一个无符号16位原始类型整数——仅此而已。对类库来说就不尽如此了，类库包含了许多可以接受char参数，并将其作为Unicode字符处理的方法。
使用字符串连接操作符使用格外小心。+ 操作符当且仅当它的操作数中至少有一个是String类型时，才会执行字符串连接操作；否则，它执行的就是加法。如果要连接的没有一个数值是字符串类型的，那么你可以有几种选择：
○预置一个空字符串
○将第一个数值用String.valueOf显式地转换成一个字符串
○使用一个字符串缓冲区
○或者如果你使用的JDK 5.0，可以用printf方法

12)     谜题12：ABC——char数组不是字符串。要想将一个char数组转换成一个字符串，就要调用String.valueOf(char[])方法。某些类库中的方法提供了对char数组的类似字符串的支持，通常是提供一个Object版本的重载方法和一个char[]版本的重载方法，而之后后者才能产生我们想要的行为。（字符串连接操作符在这些方法中没有被定义。）

13)     谜题13：畜牧场——在比较对象引用时，你应该优先使用equals方法而不是 == 操作符，除非你需要比较的是对象的标识而不是对象的值。

14)     谜题14：转义字符的溃败——Java对在字符串字面常量中的Unicode转义字符没有提供任何特殊处理。编译器在将程序解析成各种符号之前，先将Unicode转义字符转换成为它们所表示的字符[JLS 3.2]。
在字符串和字符字面常量中要优先选择的是转义字符序列，而不是Unicode转义字符。Unicode转义字符可能会因为它们在编译序列中被处理得过早而引起混乱。不要使用Unicode转义字符来表示ASCII字符。在字符串和字符字面常量中，应该使用转义字符序列；对于除这些字面常量之外的情况，应该直接将ASCII字符插入到源文件中。

15)     谜题15：令人晕头转向的Hello——要确保字符/u不出现在一个合法的Unicode转义字符上下文之外，即使是在注释中也是如此。在机器生成的代码中要特别注意此问题。

16)     谜题16：行打印程序
Unicode转义字符绝对会产生混乱。教训很简单：除非确实是必需的，否则就不要使用Unicode转义字符。它们很少是必需的。

 

17)     谜题17：嗯？——仅仅是因为你可以不以应有的方式去进行表达。或者说，如果你这么做会造成损害，那么就请不要这么做！更严肃地讲，这个谜题是对前面三个教训的补充：Unicode转义字符只有在你要向程序中插入用其他任何方式都无法表示的字符时才是必需的，除此之外的任何情况都不应该避免使用它们。Unicode转义字符降低了程序的清晰度，并且增加了产生bug的可能性。
对语言的设计者来说，也许使用Unicode转义字符来表示ASCII字符应该被定义为是非法的。这样就可以使得在谜题14、15和17（本谜题）中的程序非法，从而消除了大量的混乱。

18)     谜题18：字符串奶酪——String(byte[])构造器。有关它的规范描述道：“在通过解码使用平台缺省字符集的指定byte数组来构造一个新的String时，该新String的长度是字符集的一个函数，因此，它可能不等于byte数组的长度。当给定的所有字节在缺省字符集中并非全部有效时，这个构造器的行为是不确定的”[Java-API]。每当你要将一个byte序列转换成一个String时，你都在使用某一个字符集，不管你是否显式地指定了它。如果你想让你的程序的行为是可预知的，那么就请你在每次使用字符集时都明确地指定。

19)     谜题19：漂亮的火花——块注释不能可靠地注释掉代码段，应该用单行的注释序列来代替。

20)     谜题20：我们的类是什么？——

21)     谜题21：我们的类是什么？II——在使用不熟悉的类库方法时一定要格外小心。当你心存疑虑时，就要求助于Javadoc。还有就是正则表达式是很棘手的：它所引发的问题趋向于在运行时刻而不是在编译时刻暴露出来。

22)     谜题22：URL的愚弄——令人误解的注释和无关的代码会引起混乱。要仔细地写注释，并让它们跟上时代；要切除那些已遭废弃的代码。还有就是如果某些东西看起来过于奇怪，以至于不像对的，那么它极有可能就是错的。

23)     谜题23：不劳而获——
○要当心栅栏柱错误，每当你在处理长度、范围或模数的时候，都要仔细确定其端点是否应该被包括在内，并且要确保你的代码的行为要与其相对应。
○在switch的各种情况中缺少break语句是非常常见的错误。
○为了避免这类问题，不管在什么时候，都要尽可能使用熟悉的惯用法和API。如果你必须使用不熟悉的API，那么请仔细阅读其文档。在本例中，程序应该使用常用的接受一个String的StringBuffer构造器。
首先，要当心栅栏柱错误。其次，牢记在 switch 语句的每一个 case 中都放置一条 break 语句。第三，要使用常用的惯用法和 API，并且当你在离开老路子的时候，一定要参考相关的文档。第四，一个 char 不是一个 String，而是更像一个 int。最后，要提防各种诡异的谜题。

C．Java谜题3——循环谜题

24)     谜题24：尽情享受第一个字节——要避免混合类型比较，因为它们内在地容易引起混乱（谜题5）。为了帮助实现这个目标，请使用声明的常量替代“魔幻数字”。你已经了解了这确实是一个好主意：它说明了常量的含义，集中了常量的定义，并且根除了重复的定义。现在你知道它还可以强制你去为每一个常量赋予适合其用途的类型，从而消除了产生混合类型比较的一种根源。

25)     谜题25：无情的增量操作——这与谜题7中的教训相同：不要在单个的表达式中对相同的变量赋值超过一次。对相同的变量进行多次赋值的表达式会产生混淆，并且很少能够产生你希望的行为。

26)     谜题26：在循环中——这里的教训就是int不能表示所有的整数。无论你在何时使用了一个整数类型，都要意识到其边界条件。如果其数值下溢或是上溢了，会怎么样呢？所以通常最好是使用一个取之范围更大的类型。（整数类型包括byte、char、short、int和long。）

27)     谜题27：变幻莫测的i值——移位长度是对32取余的，或者如果左操作数是long类型的，则对64取余。因此，使用任何移位操作符和移位长度，都不可能将一个数值的所有位全部移走。同时，我们也不可能用右移操作符来执行左移操作，反之亦然。如果可能的话，请使用常量的移位长度，如果移位长度不能设为常量，那么就要千万当心。

28)     谜题28：循环者——用一个double或一个float数值来表示无穷大是可以的。大多数人在第一次听到这句话时，多少都会有一点吃惊，可能是因为我们无法用任何整数类型来表示无穷大的原因。第二点，将一个很小的浮点数加到一个很大的浮点数上时，将不会改变大的浮点数的值。这过于违背直觉了，因为对实际的数字来说这是不成立的。我们应该记住二进制浮点算术只是对实际算术的一种近似。

29)     谜题29：循环者的新娘——float和double类型都有一个特殊的NaN值，用来表示不是数字的数量。对于涉及NaN值的计算，其规则很简单也很明智，但是这些规则的结果可能是违背直觉的。

30)     谜题30：循环者的爱子——操作符重载是很容易令人误解的。在本谜题中的加号看起来是表示一个加法，但是通过为变量i选择合适的类型，即String，我们让它执行了字符串连接操作。甚至是因为变量被命名为i，都使得本谜题更加容易令人误解，因为i通常被当作整型变量名而被保留的。对于程序的可读性来说，好的变量名、方法名和类名至少与好的注释同等重要。

31)     谜题31：循环者的鬼魂——总之，不要在short、byte或char类型的变量之上使用复合赋值操作符。因为这样的表达式执行的是混合类型算术运算，它容易造成混乱。更糟的是，它们执行将隐式地执行会丢失信息的窄化转型，其结果是灾难性的。

32)     谜题32：循环者的诅咒——当两个操作数都是被包装的数字类型时，数值比较操作符和判等操作符的行为存在着根本的差异：数值比较操作符执行的是值比较，而判等操作符执行的是引用标识的比较。

33)     谜题33：循环者遇到了狼人——Java使用2的补码的算术运算，它是非对称的。对于每一种有符号的整数类型（int、long、byte和short），负的数值总是比正的数值多一个，这个多出来的值总是这种类型所能表示的最小数值。对Integer.MIN_VALUE取负值得到的还是它没有改变过的值，Long.MIN_VALUE也是如此。对Short.MIN_VALUE取负值并将所产生的int数值转型回short，返回的同样是最初的值（Short.MIN_VALUE）。对Byte.MIN_VALUE来说，也会产生相似的结果。更一般地讲，千万要当心溢出：就像狼人一样，它是个杀手。

34)     谜题34：被计数击倒了——不要使用浮点数作为循环索引，因为它会导致无法预测的行为。如果你在循环体内需要一个浮点数，那么请使用int或long循环索引，并将其转换为float或double。在将一个int或long转换成一个float或double时，你可能会丢失精度，但是至少它不会影响到循环本身。当你使用浮点数时，要使用double而不是float，除非你肯定float提供了足够的精度，并且存在强制性的性能需求迫使你使用float。适合使用float而不是double的时刻是非常非常少的。

35)     谜题35：一分钟又一分钟——然而，编译器是忽略空格的，所以千万不要使用空格来表示分组，要使用括号。空格是靠不住的，而括号是从来不说谎的。

D．Java谜题4——异常谜题

36)     谜题36：优柔寡断——每一个finally语句块都应该正常结束，除非抛出的是不受检查的异常。千万不要用一个return、break、continue或throw来退出一个finally语句块，并且千万不要允许将一个受检查的异常传播到一个finally语句块之外去。对close的调用可能会导致finally语句块意外结束。

37)     谜题37：极端不可思议——第一个程序说明了一项基本要求，即对于捕获被检查异常的catch子句，只有在相应的try子句可以抛出这些异常时才被允许。第二个程序说明了这项要求不会应用到的冷僻案例。第三个程序说明了多个继承而来的throws子句的交集，将减少而不是增加方法允许抛出的异常数量。本谜题所说明的行为一般不会引发难以捉摸的bug，但是你第一次看到它们时，可能会有点吃惊。

38)     谜题38：不受欢迎的宾客——如果你必须重构一个程序，以消除由明确赋值规则所引发的错误，那么你应该考虑添加一个新方法。这样做除了可以解决明确赋值问题，还可以使程序的可读性提高。

39)     谜题39：您好，再见！——System.exit将立即停止所有的程序线程，它并不会使finally语句块得到调用，但是它在停止VM之前会执行关闭挂钩操作。当VM被关闭时，请使用关闭挂钩来终止外部资源。通过调用System.halt可以在不执行关闭挂钩的情况下停止VM，但是这个方法很少使用。

40)     谜题40：不情愿的构造器——实例初始化操作是先于构造器的程序体而运行的。实例初始化操作抛出的任何异常都会传播给构造器。如果初始化操作抛出的是被检查异常，那么构造器必须声明也会抛出这些异常，但是应该避免这样做，因为它会造成混乱。最后，对于我们所设计的类，如果其实例包含同样属于这个类的其他实例，那么对这种无限递归要格外当心。

41)     谜题41：域和流——当你在finally语句块中调用close方法时，要用一个嵌套的try-catch语句来保护它，以防止IOException的传播。更一般地讲，对于任何在finally语句块中可能会抛出的被检查异常都要进行处理，而不是任其传播。这是谜题36中的教训的一种特例，而对语言设计者的教训情况也相同。 

42)     谜题42：异常为循环而抛——不要去用那些可怕的使用异常而不是使用显式的终止测试的循环惯用法，因为这种惯用法非常不清晰，而且会掩盖bug。要意识到逻辑AND和OR操作符的存在，并且不要因无意识的误用而受害。

43)     谜题43：异常地危险——Java的异常检查机制并不是虚拟机强制执行的。它只是一个编译期工具，被设计用来帮助我们更加容易地编写正确的程序，但是在运行期可以绕过它。要想减少你因为这类问题而被曝光的次数，就不要忽视编译器给出的警告信息。

44)     谜题44：切掉类——要想编写一个能够探测出某个类是否丢失的程序，请使用反射来引用类而不要使用通常的语言结构[EJ Item35]。总之，不要对捕获NoClassDefFoundError形成依赖。语言规范非常仔细地描述了类初始化是在何时发生的[JLS 12.4.1]，但是类被加载的时机却显得更加不可预测。更一般地讲，捕获Error及其子类型几乎是完全不恰当的。这些异常是为那些不能被恢复的错误而保留的。

45)     谜题45：令人疲惫不堪的测验——本谜题没有很多关于教训方面的东西。它证明了指数算法对于除了最小输入之外的所有情况都是不可行的，它还表明了你甚至可以不费什么劲就可以编写出一个指数算法。