Java™ Puzzlers: 深入解析编程陷阱与难题

5星 · 超过95%的资源需积分: 9 51 浏览量更新于2024-07-23 1 收藏 4.17MB PDF 举报

"《Java解惑》是一本由Joshua Bloch和Neal Gafter共同编写的书籍，主要探讨Java编程语言中的陷阱、误区和角落案例。这本书由Addison Wesley Professional出版，于2005年6月发行，共304页。书中通过一系列有趣的编程难题揭示了Java语言的独特之处，旨在帮助开发者更深入地理解Java的微妙之处。" 在《Java解惑》中，作者们以一种独特的方式——编程谜题，来揭示Java语言中可能遇到的奇怪行为和潜在问题。这些谜题不仅仅是娱乐，更是对编程技巧和理解力的挑战。通过解决这些谜题，读者可以了解如何避免常见的编程陷阱，提升编程技能，以及对Java语法和库的深层次理解。这本书面向已有一定Java编程基础的读者，无论是经验丰富的开发人员还是正在进阶的程序员，都能从中受益。书中的每个谜题都设计得既具有挑战性，又富有启发性，旨在让读者在解决问题的过程中，体验到Java语言的奇妙和复杂性。谜题涵盖的内容广泛，包括但不限于类型系统、内存模型、多线程、异常处理、集合框架、反射机制等重要领域。例如，谜题可能涉及以下主题： 1. 类型转换：Java的强制类型转换规则有时可能会带来意想不到的结果，尤其是涉及到基本类型和它们对应的包装类时。 2. 静态与非静态成员：理解何时应该使用静态成员，以及静态与非静态成员之间的交互，是避免常见问题的关键。 3. 异常处理：正确地使用try-catch-finally语句，理解异常的传播方式，以及如何避免空指针异常，都是提高代码健壮性的必要知识。 4. 多线程：Java的并发工具，如synchronized关键字、volatile变量和线程安全的集合，都有其特定的使用规则，不正确的使用可能导致数据不一致或死锁。 5. 泛型：Java泛型的边界和类型擦除可能导致一些混淆，了解这些机制可以帮助编写更安全的代码。 6. 内存管理：理解Java垃圾收集的工作原理，以及如何避免内存泄漏，对于优化程序性能至关重要。通过阅读《Java解惑》，读者不仅能够提高对Java语言的掌握，还能培养出对编程陷阱的敏锐洞察力，从而在实际开发中避免错误，提高代码质量。这本书不仅是提升个人技能的宝贵资料，也是团队内部分享和讨论的良好素材，有助于构建更高效、更稳定的Java应用程序。

System.out.printf("%.2f%n", 2.00 - 1.10);

This prints the right answer but does not represent a general solution to the underlying problem: It

still uses double arithmetic, which is binary floating-point. Floating-point arithmetic provides good

approximations over a wide range of values but does not generally yield exact results. Binary

floating-point is particularly ill-suited to monetary calculations, as it is impossible to represent

0.1— or any other negative power of 10— exactly as a finite-length binary fraction [EJ Item 31].

One way to solve the problem is to use an integral type, such as int or long, and to perform the

computation in cents. If you go this route, make sure the integral type is large enough to represent

all the values you will use in your program. For this puzzle, int is ample. Here is how the println

looks if we rewrite it using int values to represent monetary values in cents. This version prints 90

cents, which is the right answer:

System.out.println((200 - 110) + " cents");

Another way to solve the problem is to use BigDecimal, which performs exact decimal arithmetic.

It also interoperates with the SQL DECIMAL type via JDBC. There is one caveat: Always use the

BigDecimal(String) constructor, never BigDecimal(double). The latter constructor creates an

instance with the exact value of its argument: new BigDecimal(.1) returns a BigDecimal

representing 0.1000000000000000055511151231257827021181583404541015625. Using

BigDecimal correctly, the program prints the expected result of 0.90:

import java.math.BigDecimal;

public class Change {

public static void main(String args[]) {

System.out.println(new BigDecimal("2.00").

subtract(new BigDecimal("1.10")));

}

This version is not terribly pretty, as Java provides no linguistic support for BigDecimal.

Calculations with BigDecimal are also likely to be slower than those with any primitive type, which

might be an issue for some programs that make heavy use of decimal calculations. It is of no

consequence for most programs.

In summary, avoid float and double where exact answers are required; for monetary

< Day Day Up >

Puzzle 3: Long Division

This puzzle is called Long Division because it concerns a program that divides two long values.

The dividend represents the number of microseconds in a day; the divisor, the number of

milliseconds in a day. What does the program print?

public class LongDivision {

public static void main(String[] args) {

final long MICROS_PER_DAY = 24 * 60 * 60 * 1000 * 1000;

final long MILLIS_PER_DAY = 24 * 60 * 60 * 1000;

System.out.println(MICROS_PER_DAY / MILLIS_PER_DAY);

}

Solution 3: Long Division

This puzzle seems reasonably straightforward. The number of milliseconds per day and the number

of microseconds per day are constants. For clarity, they are expressed as products. The number of

microseconds per day is (24 hours/day · 60 minutes/hour · 60 seconds/minute · 1,000

milliseconds/second · 1,000 microseconds/millisecond). The number of milliseconds per day differs

only in that it is missing the final factor of 1,000. When you divide the number of microseconds per

day by the number of milliseconds per day, all the factors in the divisor cancel out, and you are left

with 1,000, which is the number of microseconds per millisecond. Both the divisor and the dividend

are of type long, which is easily large enough to hold either product without overflow. It seems,

then, that the program must print 1000. Unfortunately, it prints 5. What exactly is going on here?

The problem is that the computation of the constant MICROS_PER_DAY does overflow. Although the

result of the computation fits in a long with room to spare, it doesn't fit in an int. The computation

is performed entirely in int arithmetic, and only after the computation completes is the result

promoted to a long. By then, it's too late: The computation has already overflowed, returning a

value that is too low by a factor of 200. The promotion from int to long is a widening primitive

conversion [JLS 5.1.2], which preserves the (incorrect) numerical value. This value is then divided

by MILLIS_PER_DAY, which was computed correctly because it does fit in an int. The result of this

division is 5.

So why is the computation performed in int arithmetic? Because all the factors that are multiplied

剩余377页未读，继续阅读

浪中云

粉丝: 33
资源: 19

Java™ Puzzlers: 深入解析编程陷阱与难题

Java Puzzlers 中文版（Java解惑）

java谜题中文版

JAVA PUZZLERS（JAVA 解惑）中英文

关于java的参考文献

JavaSIG-Puzzlers.pdf

java Puzzlers 中文版带完整目录

Java解惑（中文版）

java puzzles.pdf

Java解惑（中文）.pdf

javaPuzzlers中文.pdf

最新资源