描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121342608
产品特色
编辑推荐
√ 经典原味，Effective Java 升级版
√ Google 首席Java架构师倾情力作
√ 涵盖Java 7、Java 8和Java 9中的各种新特性
√ Google 首席Java架构师倾情力作
√ 涵盖Java 7、Java 8和Java 9中的各种新特性
内容简介
自从Java 6发布之后，Java又有了翻天覆地的变化。本书涵盖了Java 7、Java 8和Java 9中语言和库的各种新特性。让你能够深入了解Java平台的细微之处。通过对每一个项目的全面描述和解释，告诉你应该做什么、不应该做什么，以及为什么要这样做。
目 录
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Creating and Destroying Objects . . . . . . . . . . . . . . . . . . . . . 5
Item 1: Consider static factory methods instead of constructors . . . 5
Item 2: Consider a builder when faced with many constructor parameters . .. . . . . . . . 10
Item 3: Enforce the singleton property with a private constructor or an enum type . . . . . . . . . . . . . . . 17
Item 4: Enforce noninstantiability with a private constructor . . . . 19
Item 5: Prefer dependency injection to hardwiring resources . . . . 20
Item 6: Avoid creating unnecessary objects . . . . . . . . . . . . . . . . . 22
Item 7: Eliminate obsolete object references . . . . . . . . . . . . . . . . . 26
Item 8: Avoid finalizers and cleaners . . . . . . . . . . . . . . . . . . . . . . 29
Item 9: Prefer try-with-resources to try-finally. . . . . . . . . . . . 34
3 Methods Common to All Objects . . . . . . . . . . . . . . . . . . . . 37
Item 10: Obey the general contract when overriding equals . . . . . 37
Item 11: Always override hashCode when you override equals . . 50
Item 12: Always override toString . . . . . . . . . . . . . . . . . . . . . . . . 55
Item 13: Override clone judiciously . . . . . . . . . . . . . . . . . . . . . . . . 58
Item 14: Consider implementing Comparable . . . . . . . . . . . . . . . . 66
4 Classes and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Item 15: Minimize the accessibility of classes and members . . . . . 73
Item 16: In public classes, use accessor methods, not public fields 78
Item 17: Minimize mutability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Item 18: Favor composition over inheritance . . . . . . . . . . . . . . . . . 87
Item 19: Design and document for inheritance or else prohibit it 93
Item 20: Prefer interfaces to abstract classes . . . . . . . . . . . . . . . . . 99
Item 21: Design interfaces for posterity . . . . . . . . . . . . . . . . . . . . 104
Item 22: Use interfaces only to define types. . . . . . . . . . . . . . . . . 107
Item 23: Prefer class hierarchies to tagged classes . . . . . . . . . . . . 109
Item 24: Favor static member classes over nonstatic . . . . . . . . . . 112
Item 25: Limit source files to a single top-level class . . . . . . . . . 115
5 Generics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Item 26: Don’t use raw types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Item 27: Eliminate unchecked warnings. . . . . . . . . . . . . . . . . . . . 123
Item 28: Prefer lists to arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Item 29: Favor generic types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Item 30: Favor generic methods . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Item 31: Use bounded wildcards to increase API flexibility . . . . 139
Item 32: Combine generics and varargs judiciously. . . . . . . . . . . 146
Item 33: Consider typesafe heterogeneous containers . . . . . . . . . 151
6 Enums and Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Item 34: Use enums instead of int constants. . . . . . . . . . . . . . . . 157
Item 35: Use instance fields instead of ordinals . . . . . . . . . . . . . . 168
Item 36: Use EnumSet instead of bit fields . . . . . . . . . . . . . . . . . . 169
Item 37: Use EnumMap instead of ordinal indexing. . . . . . . . . . . . 171
Item 38: Emulate extensible enums with interfaces . . . . . . . . . . . 176
Item 39: Prefer annotations to naming patterns . . . . . . . . . . . . . . 180
Item 40: Consistently use the Override annotation. . . . . . . . . . . 188
Item 41: Use marker interfaces to define types . . . . . . . . . . . . . . 191
7 Lambdas and Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Item 42: Prefer lambdas to anonymous classes . . . . . . . . . . . . . . 193
Item 43: Prefer method references to lambdas . . . . . . . . . . . . . . . 197
Item 44: Favor the use of standard functional interfaces . . . . . . . 199
Item 45: Use streams judiciously . . . . . . . . . . . . . . . . . . . . . . . . . 203
Item 46: Prefer side-effect-free functions in streams . . . . . . . . . . 210
Item 47: Prefer Collection to Stream as a return type. . . . . . . . . . 216
Item 48: Use caution when making streams parallel . . . . . . . . . . 222
8 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Item 49: Check parameters for validity . . . . . . . . . . . . . . . . . . . . . 227
Item 50: Make defensive copies when needed . . . . . . . . . . . . . . . 231
Item 51: Design method signatures carefully . . . . . . . . . . . . . . . . 236
Item 52: Use overloading judiciously . . . . . . . . . . . . . . . . . . . . . . 238
Item 53: Use varargs judiciously . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Item 54: Return empty collections or arrays, not nulls . . . . . . . . . 247
Item 55: Return optionals judiciously . . . . . . . . . . . . . . . . . . . . . . 249
Item 56: Write doc comments for all exposed API elements . . . . 254
9 General Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Item 57: Minimize the scope of local variables . . . . . . . . . . . . . . . 261
Item 58: Prefer for-each loops to traditional for loops . . . . . . . . . 264
Item 59: Know and use the libraries . . . . . . . . . . . . . . . . . . . . . . . 267
Item 60: Avoid float and double if exact answers are required . 270
Item 61: Prefer primitive types to boxed primitives . . . . . . . . . . . 273
Item 62: Avoid strings where other types are more appropriate . . 276
Item 63: Beware the performance of string concatenation . . . . . . 279
Item 64: Refer to objects by their interfaces . . . . . . . . . . . . . . . . . 280
Item 65: Prefer interfaces to reflection . . . . . . . . . . . . . . . . . . . . . 282
Item 66: Use native methods judiciously. . . . . . . . . . . . . . . . . . . . 285
Item 67: Optimize judiciously . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Item 68: Adhere to generally accepted naming conventions . . . . . 289
10 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Item 69: Use exceptions only for exceptional conditions . . . . . . . 293
Item 70: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors . . 296
Item 71: Avoid unnecessary use of checked exceptions . . . . . . . . 298
Item 72: Favor the use of standard exceptions. . . . . . . . . . . . . . . . 300
Item 73: Throw exceptions appropriate to the abstraction. . . . . . . 302
Item 74: Document all exceptions thrown by each method. . . . . . 304
Item 75: Include failure-capture information in detail messages. . 306
Item 76: Strive for failure atomicity . . . . . . . . . . . . . . . . . . . . . . . 308
Item 77: Don’t ignore exceptions . . . . . . . . . . . . . . . . . . . . . . . . . 310
11 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Item 78: Synchronize access to shared mutable data . . . . . . . . . . 311
Item 79: Avoid excessive synchronization . . . . . . . . . . . . . . . . . . 317
Item 80: Prefer executors, tasks, and streams to threads . . . . . . . 323
Item 81: Prefer concurrency utilities to wait and notify . . . . . . 325
Item 82: Document thread safety . . . . . . . . . . . . . . . . . . . . . . . . . 330
Item 83: Use lazy initialization judiciously . . . . . . . . . . . . . . . . . 333
Item 84: Don’t depend on the thread scheduler . . . . . . . . . . . . . . 336
12 Serialization
2 Creating and Destroying Objects . . . . . . . . . . . . . . . . . . . . . 5
Item 1: Consider static factory methods instead of constructors . . . 5
Item 2: Consider a builder when faced with many constructor parameters . .. . . . . . . . 10
Item 3: Enforce the singleton property with a private constructor or an enum type . . . . . . . . . . . . . . . 17
Item 4: Enforce noninstantiability with a private constructor . . . . 19
Item 5: Prefer dependency injection to hardwiring resources . . . . 20
Item 6: Avoid creating unnecessary objects . . . . . . . . . . . . . . . . . 22
Item 7: Eliminate obsolete object references . . . . . . . . . . . . . . . . . 26
Item 8: Avoid finalizers and cleaners . . . . . . . . . . . . . . . . . . . . . . 29
Item 9: Prefer try-with-resources to try-finally. . . . . . . . . . . . 34
3 Methods Common to All Objects . . . . . . . . . . . . . . . . . . . . 37
Item 10: Obey the general contract when overriding equals . . . . . 37
Item 11: Always override hashCode when you override equals . . 50
Item 12: Always override toString . . . . . . . . . . . . . . . . . . . . . . . . 55
Item 13: Override clone judiciously . . . . . . . . . . . . . . . . . . . . . . . . 58
Item 14: Consider implementing Comparable . . . . . . . . . . . . . . . . 66
4 Classes and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Item 15: Minimize the accessibility of classes and members . . . . . 73
Item 16: In public classes, use accessor methods, not public fields 78
Item 17: Minimize mutability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Item 18: Favor composition over inheritance . . . . . . . . . . . . . . . . . 87
Item 19: Design and document for inheritance or else prohibit it 93
Item 20: Prefer interfaces to abstract classes . . . . . . . . . . . . . . . . . 99
Item 21: Design interfaces for posterity . . . . . . . . . . . . . . . . . . . . 104
Item 22: Use interfaces only to define types. . . . . . . . . . . . . . . . . 107
Item 23: Prefer class hierarchies to tagged classes . . . . . . . . . . . . 109
Item 24: Favor static member classes over nonstatic . . . . . . . . . . 112
Item 25: Limit source files to a single top-level class . . . . . . . . . 115
5 Generics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Item 26: Don’t use raw types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Item 27: Eliminate unchecked warnings. . . . . . . . . . . . . . . . . . . . 123
Item 28: Prefer lists to arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Item 29: Favor generic types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Item 30: Favor generic methods . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Item 31: Use bounded wildcards to increase API flexibility . . . . 139
Item 32: Combine generics and varargs judiciously. . . . . . . . . . . 146
Item 33: Consider typesafe heterogeneous containers . . . . . . . . . 151
6 Enums and Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Item 34: Use enums instead of int constants. . . . . . . . . . . . . . . . 157
Item 35: Use instance fields instead of ordinals . . . . . . . . . . . . . . 168
Item 36: Use EnumSet instead of bit fields . . . . . . . . . . . . . . . . . . 169
Item 37: Use EnumMap instead of ordinal indexing. . . . . . . . . . . . 171
Item 38: Emulate extensible enums with interfaces . . . . . . . . . . . 176
Item 39: Prefer annotations to naming patterns . . . . . . . . . . . . . . 180
Item 40: Consistently use the Override annotation. . . . . . . . . . . 188
Item 41: Use marker interfaces to define types . . . . . . . . . . . . . . 191
7 Lambdas and Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Item 42: Prefer lambdas to anonymous classes . . . . . . . . . . . . . . 193
Item 43: Prefer method references to lambdas . . . . . . . . . . . . . . . 197
Item 44: Favor the use of standard functional interfaces . . . . . . . 199
Item 45: Use streams judiciously . . . . . . . . . . . . . . . . . . . . . . . . . 203
Item 46: Prefer side-effect-free functions in streams . . . . . . . . . . 210
Item 47: Prefer Collection to Stream as a return type. . . . . . . . . . 216
Item 48: Use caution when making streams parallel . . . . . . . . . . 222
8 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Item 49: Check parameters for validity . . . . . . . . . . . . . . . . . . . . . 227
Item 50: Make defensive copies when needed . . . . . . . . . . . . . . . 231
Item 51: Design method signatures carefully . . . . . . . . . . . . . . . . 236
Item 52: Use overloading judiciously . . . . . . . . . . . . . . . . . . . . . . 238
Item 53: Use varargs judiciously . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Item 54: Return empty collections or arrays, not nulls . . . . . . . . . 247
Item 55: Return optionals judiciously . . . . . . . . . . . . . . . . . . . . . . 249
Item 56: Write doc comments for all exposed API elements . . . . 254
9 General Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Item 57: Minimize the scope of local variables . . . . . . . . . . . . . . . 261
Item 58: Prefer for-each loops to traditional for loops . . . . . . . . . 264
Item 59: Know and use the libraries . . . . . . . . . . . . . . . . . . . . . . . 267
Item 60: Avoid float and double if exact answers are required . 270
Item 61: Prefer primitive types to boxed primitives . . . . . . . . . . . 273
Item 62: Avoid strings where other types are more appropriate . . 276
Item 63: Beware the performance of string concatenation . . . . . . 279
Item 64: Refer to objects by their interfaces . . . . . . . . . . . . . . . . . 280
Item 65: Prefer interfaces to reflection . . . . . . . . . . . . . . . . . . . . . 282
Item 66: Use native methods judiciously. . . . . . . . . . . . . . . . . . . . 285
Item 67: Optimize judiciously . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Item 68: Adhere to generally accepted naming conventions . . . . . 289
10 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Item 69: Use exceptions only for exceptional conditions . . . . . . . 293
Item 70: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors . . 296
Item 71: Avoid unnecessary use of checked exceptions . . . . . . . . 298
Item 72: Favor the use of standard exceptions. . . . . . . . . . . . . . . . 300
Item 73: Throw exceptions appropriate to the abstraction. . . . . . . 302
Item 74: Document all exceptions thrown by each method. . . . . . 304
Item 75: Include failure-capture information in detail messages. . 306
Item 76: Strive for failure atomicity . . . . . . . . . . . . . . . . . . . . . . . 308
Item 77: Don’t ignore exceptions . . . . . . . . . . . . . . . . . . . . . . . . . 310
11 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Item 78: Synchronize access to shared mutable data . . . . . . . . . . 311
Item 79: Avoid excessive synchronization . . . . . . . . . . . . . . . . . . 317
Item 80: Prefer executors, tasks, and streams to threads . . . . . . . 323
Item 81: Prefer concurrency utilities to wait and notify . . . . . . 325
Item 82: Document thread safety . . . . . . . . . . . . . . . . . . . . . . . . . 330
Item 83: Use lazy initialization judiciously . . . . . . . . . . . . . . . . . 333
Item 84: Don’t depend on the thread scheduler . . . . . . . . . . . . . . 336
12 Serialization
前 言
前言
1997年，Java还年轻时，James Gosling（Java 之父）称它为“蓝领的语言”（blue collar language），以此来表达它“十分简单”[Gosling97]。几乎与此同时，Bjarne Stroustrup（C 之父）将C 称为“多范式语言”（multi-paradigm language），“故意和那些只能用单一方式编写程序的语言区别开来”[Stroustrup95]。Stroustrup警告说：
Java相对的简单性——和大多数新语言一样——一部分是因为错觉，另一部分是因为它的不完整性。随着时间的推移，Java的规模和复杂性将显著增长。它的规模将增加两到三倍，相关的扩展和库也会不断增加。
现在，20年过去了，公平来讲，Gosling和Stroustrup都是正确的。Java现在变得复杂且庞大，从并行执行、迭代，到日期和时间表示法都有多个抽象。
虽然我的热情随着平台的发展已经冷却，但我仍然喜欢Java，鉴于其规模和复杂性的增长，我们迫切需要一个的实践指南，这就是本书写作的目的。我希望这个版本能够在延续旧版本理念的前提下满足大家新的需求。
小很美，简单却不易。
圣何塞，加利福尼亚
2017年11月
附言：
如果我没有提及近占据我大量时间去践行的业内实践，那将是我的疏忽。自20世纪50年代这个行业诞生以来，我们可以自由地重新实现彼此的API。这种做法是计算机技术迅速成功的关键。我以实际行动致力于维护这种自由[CompSci17]，我希望你能加入进来。保留彼此可以重新实现API的权利，这对于维持行业健康发展至关重要。
致谢
感谢第1版和第2版的读者用你们的热情来接纳这本书，将它的理念铭记于心，并且让我知道它对你们的工作有那么多积极的影响。感谢众多的讲师在你们的课程中使用这本书，感谢众多的工程师团队采用这本书。
感谢Addison-Wesley和Pearson团队在高强度的工作压力下依旧善良、专业、耐心、优雅。在整个过程中，我的编辑Greg Doench一直保持镇定：他是一位好编辑，同时也是一名优雅的绅士。为了这个项目他恐怕生了不少白发，在此我向他道歉。我的项目经理Julie Nahil和我的项目编辑Dana Wilson像我期望的那样勤奋、准时、有条理、友好。我的文字编辑Kim Wimpsett一丝不苟且极有品味。
我再次拥有了梦寐以求的审校团队，在此致以我诚挚的谢意。几乎检查了每一章的核心团队包括：Cindy Bloch、Brian Kernighan、Kevin Bourrillion、Joe Bowbeer、William Chargin、Joe Darcy、Brian Goetz、Tim Halloran、Stuart Marks、Tim Peierls，以及Yoshiki Shibata。其他审校包括：Marcus Biel、Dan Bloch、Beth Bottos、Martin Buchholz、Michael Diamond、Charlie Garrod、Tom Hawtin、Doug Lea、Aleksey Shipil?v、Lou Wasserman，以及Peter Weinberger。这些审校人员提出了很多建议，大大提升了本书的品质，也避免了很多尴尬的错误。
另外，要专门感谢William Chargin、Doug Lea和Tim Peierls。他们是本书很多理念的“扩音器”。William、Doug和Tim孜孜不倦地为本书付出了他们的时间和智慧。
后，感谢我的妻子Cindy Bloch一直鼓励我写作、阅读了所有的原始文档、编写了索引，并一直帮助我处理这个项目中会出现的各种事情，以及在我写作时包容我。
1997年，Java还年轻时，James Gosling（Java 之父）称它为“蓝领的语言”（blue collar language），以此来表达它“十分简单”[Gosling97]。几乎与此同时，Bjarne Stroustrup（C 之父）将C 称为“多范式语言”（multi-paradigm language），“故意和那些只能用单一方式编写程序的语言区别开来”[Stroustrup95]。Stroustrup警告说：
Java相对的简单性——和大多数新语言一样——一部分是因为错觉，另一部分是因为它的不完整性。随着时间的推移，Java的规模和复杂性将显著增长。它的规模将增加两到三倍，相关的扩展和库也会不断增加。
现在，20年过去了，公平来讲，Gosling和Stroustrup都是正确的。Java现在变得复杂且庞大，从并行执行、迭代，到日期和时间表示法都有多个抽象。
虽然我的热情随着平台的发展已经冷却，但我仍然喜欢Java，鉴于其规模和复杂性的增长，我们迫切需要一个的实践指南，这就是本书写作的目的。我希望这个版本能够在延续旧版本理念的前提下满足大家新的需求。
小很美，简单却不易。
圣何塞，加利福尼亚
2017年11月
附言：
如果我没有提及近占据我大量时间去践行的业内实践，那将是我的疏忽。自20世纪50年代这个行业诞生以来，我们可以自由地重新实现彼此的API。这种做法是计算机技术迅速成功的关键。我以实际行动致力于维护这种自由[CompSci17]，我希望你能加入进来。保留彼此可以重新实现API的权利，这对于维持行业健康发展至关重要。
致谢
感谢第1版和第2版的读者用你们的热情来接纳这本书，将它的理念铭记于心，并且让我知道它对你们的工作有那么多积极的影响。感谢众多的讲师在你们的课程中使用这本书，感谢众多的工程师团队采用这本书。
感谢Addison-Wesley和Pearson团队在高强度的工作压力下依旧善良、专业、耐心、优雅。在整个过程中，我的编辑Greg Doench一直保持镇定：他是一位好编辑，同时也是一名优雅的绅士。为了这个项目他恐怕生了不少白发，在此我向他道歉。我的项目经理Julie Nahil和我的项目编辑Dana Wilson像我期望的那样勤奋、准时、有条理、友好。我的文字编辑Kim Wimpsett一丝不苟且极有品味。
我再次拥有了梦寐以求的审校团队，在此致以我诚挚的谢意。几乎检查了每一章的核心团队包括：Cindy Bloch、Brian Kernighan、Kevin Bourrillion、Joe Bowbeer、William Chargin、Joe Darcy、Brian Goetz、Tim Halloran、Stuart Marks、Tim Peierls，以及Yoshiki Shibata。其他审校包括：Marcus Biel、Dan Bloch、Beth Bottos、Martin Buchholz、Michael Diamond、Charlie Garrod、Tom Hawtin、Doug Lea、Aleksey Shipil?v、Lou Wasserman，以及Peter Weinberger。这些审校人员提出了很多建议，大大提升了本书的品质，也避免了很多尴尬的错误。
另外，要专门感谢William Chargin、Doug Lea和Tim Peierls。他们是本书很多理念的“扩音器”。William、Doug和Tim孜孜不倦地为本书付出了他们的时间和智慧。
后，感谢我的妻子Cindy Bloch一直鼓励我写作、阅读了所有的原始文档、编写了索引，并一直帮助我处理这个项目中会出现的各种事情，以及在我写作时包容我。
评论
还没有评论。