On Java 中文版 进阶卷读后感锦集

《On Java 中文版 进阶卷》是一本由[美] Bruce Eckel著作，人民邮电出版社出版的精装图书，本书定价：129.8，页数：560，特精心收集的读后感，希望对大家能有帮助。

《On Java 中文版 进阶卷》读后感(一)：《On Java中文版 进阶卷》

《On Java》这本书我是从去年开始读的，因为本科时接触过java语言，所以学习起来并不是特别难。从基础卷到进阶卷，我感觉就像在游戏中打怪升级一样，能力需要一级一级提高。这套书给我最大的感受是真的是一本最大范围介绍java语言的书，基本所有的知识点和进阶的技术都涉及到了，整本书给人一种厚实和想要学习的欲望。 因为目前在研究一些关于自动驾驶远程控制的内容，并需要用到java的一些技术，于是我又拿起这本书来重新阅读了。书中的代码和注释以及知识点的讲解，让我这次阅读又获得了新的心得和体会。因为Java是一门面向对象的编程语言，不仅吸收了C++语言的各种优点，还摒弃了C++里难以理解的多继承、指针等概念，因此Java语言具有功能强大和简单易用两个特征。它作为静态面向对象编程语言的代表，极好地实现了面向对象理论，给了写代码的程序员很多创作的机会。

《On Java 中文版 进阶卷》读后感(二)：很不错的一本书+勘误

《On Java》进阶卷整体写的很不错，我大致看了前5章以及一小部分附录内容，读完后感觉收获很大，从第3章集合开始，就开始作者的代码展示阶段，重新温习了集合以及流的知识，很不错的地方就是：集合中的一些代码改用流重写了，让我体会到了Java 8的收集器的简洁优雅，第5章并发编程讲述了比较新的并行流以及CompletableFutuere的一些相关知识，收获很大，附录作者也很良心，介绍了有助于加深理解java的一些知识点，很遗憾，只读完了hashcode（）部分内容，有机会有时间再读其他部分，巩固Java 基础。

基础卷的勘误在这里：https://book.douban.com/review/14461004/

勘误说明：

我是用《Java编程思想》入门的Java，也是这本书的粉丝；出了新版Java，买来收藏顺便查阅新特性，觉得好书就应该发挥更好的启蒙作用，让更多读者从这些好书中受益，我本无心纠错，但是在阅读过程中的有些错误，我感觉会让初学者有疑惑，出于严谨角度（感觉自己有点过分了），我对阅读过程中出现的翻译问题列举在本书评的最下方，供读者查阅。

注意：我阅读过程中的纠错初衷是要这本书翻译的更好，出自己作为读者的一份力，真希望书再次印刷那会，可以减少一部分读者的阅读障碍，我不希望我看过的好书因为翻译问题而被诟病；我作为读者，衷心希望这本书的错误减小到最少；当然有些我提的翻译建议不一定完全适合本书（我给译者的建议还是那样子：尽量还是不改变原意的前提下翻译；好了说了这么多，这当然是自己的碎碎念，谨代表个人观点，如果觉得我的建议不妥，跳过就是了）。

另外，勘误里除个别错误会踩坑外，其他错误不影响整体阅读理解本书，我的初衷是：尽量让这本书的翻译工作做得更好，当然出版社看到，最好不过了，更正书籍错误，让这本书惠及越来越多的读者，让这本书的知识价值越来越高！

进阶卷勘误如下：

封面内容提要：

“67条关于低级程序设计”改为“67条关于底层程序设计”

第1章枚举类型

1.P4 第3段（翻译建议）：“虽然本例构造方法是私有的”改为“虽然本例构造器是私有的”

说明：全书将constructor翻译为构造器，那么保持一致吧，虽然有些书籍把constructor翻译为构造方法。

2.P4最下（译者可能对重写还有重载有误解）：“重载枚举类型中的方法”改为“重写（Overriding）枚举类型中的方法”

本小节所有有关“重载”一词均改为“重写”。

3.P10

最上面一段：“但是此处的CartoonCharacter对象可以传入任何将Supplier对象作为参数的方法”改为“然而，任何采用Supplier的方法都可以接受CartoonCharacter”

4.P14

第一段：“聚合”改为“收集”

说明：Java里有对聚合专门的定义，个人理解根据英文原文译文收集比较好。

5.P15

1.8节第二段

有关涉及的所有：“性能”改为“速度”

说明：影响性能由很多因素组成，比如：数据大小、源数据结构、可用CPU核数量，以及处理每个元素花费的时间，不能以偏概全，英文原文也是speed。

6.P16

第一段我觉得描述有点问题，显示参数在jdk文档里为1-5个，具体得问英文原作者。

7.P17

第一段：“性能非常好”改为“速度很快”

8.P18

第3段：“相较于常量特定方法（constant-specific method，参见本书第四章）”改为“相较于常量特定方法（constant-specific method，接下来描述（described next））”

9.P28（翻译建议）

第一段我总觉得翻译有些问题：根据程序描述，以及上下文，我觉得应这么翻译：注意Input中的开头两行枚举实例对应着金额，所以在接口中定义了amount()方法，然而对于另外两个枚举实例调用amount()是不合适的，如果调用就会抛出异常。

第2章对象传递和返回

10.P78

4.“并实现适用于所有字段的正确复制行为”改为“从而为任何字段生成正确的复制行为”

11.P90（翻译建议）：“Mutable则是所实现的协同类”改为“Mutable则是所实现的伴生类”

12.P92

2.“这只有在这两个引用都应该指向不同的对象时”改为“这只有在假定这两个引用都指向不同的对象时”

第3章 集合主题

13.P110

第1段：Pairs 只读的“信息传输对象（Data Transfer Object）”改为“数据传输对象（Data Transfer Object）”

14.P112第1段:通过继承java.util.Abstract类改为“通过继承java.util.Abstract的一些类；“上面的示例”改为“最后一个例子”（国家首都例子）

15.P129

最后一段：

“这个示例演示了要配合某个特定的Set实现来使用时，一个类型需要实现的方法”改为“这个示例演示了成功使用具有特定Set实现的类型所需的方法”

第4章 注解

16.P163

@Override：“用来声明该方法的定义会重载……”改为“用来声明该方法的定义会重写……”

第5章 并发编程

17.P205（可选翻译瑕疵）

并发定义：“一个任务必须要等待输入才能执行”改为“一个任务必须要等待某个（some input）输入才能执行”

纯并发：“但是无法利用多处理器进一步提升性能”改为“但是如果有更多处理器，则运行速度不会更快”

并发式并行：“使程序能利用多处理器实现更高的性能”改为“使程序能够利用多处理器并更快的产生结果”

18.P209 5.3并发为速度而生（可选翻译瑕疵）

既然标题已经翻译为了并发为速度而生，那么段落翻译就不要翻译为性能了吧

“性能问题乍一看很简单”改为“速度问题乍一看很简单”

“性能的提升越来越倾向于多处理器并行的方向”改为“速度的提升越来越倾向于多处理器并行的方向”

19.P215（翻译建议）

C语言是低级语言改为C语言是原始的。

“使得在将低级语言模型直接照搬到高级语言的过程中”改为“使得在将原始语言模型直接照搬到复杂语言的过程中”

注：在我的认知里，c语言计算机术语里是高级语言，当然也有人认为是低级语言，这只是个翻译建议

20.p217

5.8节“低级Thread的对象池”改为“底层Thread的对象池”

21.P224

5.7.2 parallel()和limit()的作用最后一句（翻译建议）：“则需要使用这些算法专门为流优化后的版本”改为“则需要使用这些专门为流优化后的算法”

22.p226

最后一段：1204次改为“1024次”

23.P237

最上：“我们可以将非Runnable和Callable类型的参数传递给ExecutorService”改为“我们可以将非Runnable和非Callable类型的参数传递给ExecutorService”

24.P245

“具体来说，即针对只在任务完成或失败时存在以用来展示的CompletableFuture”改为“也就是说，CompletableFuture仅仅存在于用来展示任务完成或失败时”

25.P247

正数第五段：“并且是特殊情况下的完成”改为“并且是异常情况下的完成”

26.P251（翻译建议）

5.10.4 上面一段：“到最终CompletableFuture 的荷载中”改为“到最终CompletableFuture的 负载中”

27.P264

5.12构造器并不是线程安全的

第二段：“因为这样做会阻塞正在构造的对象”改为“因为这样做会锁定正在构造的对象”

28.P267

第二段：

“……这会阻塞正在创建的对象”改为“……这会锁定正在构造的对象”

“因此synchronized的构造器实际上会阻塞Class对象”改为“因此synchronized的构造器实际上会锁定Class对象”

说明：熟悉操作系统的都知道，拿进程为例来说，阻塞是等待I/O完成，即进程在该I/O操作完成后才能继续执行，这时将该进程阻塞起来，而跟锁呢，就好比某个临界资源需要被互斥访问，当某进程访问该临界资源时，会有一把锁将该临界区锁起来，执行任务，等进程退出该临界区后，才释放该临界资源，所以阻塞与锁不是一回事，译者理解有误。

29.P439

23条：“从调用方程序员”改外“客户程序员”

说明：既然在基础卷里 介绍private的时候就用把 client programmer翻译为客户程序员，这里也要保持一致吧

P444

23条

“在调用方程序员完成对象的使用后”改外“在客户程序员完成对象的使用后”

30.P458

倒数第三段：或者取消hashcode中的第[2]行注释改为“或者在hashcode（）中切换到第2行”，

说明：取消注释两行都有return显然不能这么翻译。

31.p464

第一段：与Map接口一样，它返回旧键改为“与Map接口一样，它返回旧值（oldVlaue）”。

32.p459

倒数第二段：“。但是在定义这些方法时如果不想着哈希结构，这些对象在哈希数据结构中就不会表现正常改为“，但是这些对象在哈希数据结构中的表现不会正确，除非这些方法是在考虑哈希结构的情况下定义的。”

33.p464

第一段。与Map接口一样，它返回了旧键改为“它返回了旧值（oldvalue）”（英文原版也错了）。

《On Java 中文版 进阶卷》读后感(三)：思维导图学《On Java》基础卷 + 进阶卷

说明#

原来读过 《Java 编程思想（第 4 版）》，但是这个版本还是基于 Java 5 讲解。由于 Java 8 做出了非常大的改进（是 Java 变化最大的版本），且截止到 2022-07-22，Java 版本都更新到 18 了……原来那本书确实需要更新了。

原作者 Bruce Eckel 又重新出版了新书：《On Java 中文版 基础卷》 和 《On Java 中文版 进阶卷》。本文是对基础卷和进阶卷的思维导图笔记总结，略过了部分较为基础的章节，并未完全详尽书中所有知识点。

本文地址发布在 https://github.com/LjyYano/Thinking_in_Java_MindMapping 上，GitHub 地址：链接，请在转载时标明原文链接~

有几个章节过于基础，没有放在思维导图上：

我的语言之局限，即我的世界之局限。这句话不仅适用于我们日常读写的语言，也适用于编程语言。很微妙的一件事是，一门语言会悄然无息地引导你进入某种思维模式，同时远离其他思维模式。Java 尤其如此。

如果你了解一门语言的不足之处和局限性，当你遇到某个语言特性不可用时，就不会被卡住，以致无法继续。同时，因为你已经知晓其局限性，所以就可以更好地进行程序设计。

Java 8 包含了许多基础和重要的改进，而由于 Java 一直严格遵守自己的向后兼容性承诺，做出这些改进无疑需要花费相当多的精力。

如果一开始就将你的项目“发展”成一个有机的、进化的生命体，而不是像建造玻璃墙的摩天大楼一样进行一次性施工，你将获得更大的成功和更直接的反馈。

相关链接：

工具已经越来越不像机器，而是越来越像思维的一部分。

所有编程语言都是一种抽象。

如果我可以将问题从表象中抽取出来，那么什么样的对象可以马上解决我的问题呢？

相关链接：

任何抽象都应该由真正的需求来驱动。接口应该是在必要时用来重构的东西，而不是在任何地方都多加一个间接层级，进而带来额外的复杂性。这种额外的复杂性影响很大，如果你让某人在克服这种复杂性上花费时间，而他最终却发现你添加接口只不过是为了“以防万一”，而非出于什么令人信服的其他理由，他就会质疑你做过的其他所有设计。

相关链接：

lambda 表达式和方法引用远非完美，我们要永远承受 Java 设计者在语言诞生初期的草率决定所导致的代价。lambda 在 Java 并非一等公民。这并不意味着 Java 8 没有大的改进，但确实意味着，像许多 Java 语法一样，最终会有一个让你感到不爽的临界点。

相关链接：

相关链接：

异常处理的优点之一，就是它使得你可以在某处集中精力处理你要解决的问题，而在另一处处理你编写代码产生的错误。

Java 坚定地强调将所有的错误都以异常形式报告的这一事实，正是它远超过诸如 C++ 这类语言的长处之一。

相关链接：

在非常难用的文件 I/O 编程存在多年之后，Java 终于简化了读写文件的基本操作。

相关链接：

相关链接：

在 Java 中，泛型是在这门语言发布了几乎 10 年后才引入的，所以向泛型的迁移问题是必须要考虑的，也对泛型的设计产生了很大冲击。结果就是，作为程序员的你，将因为 Java 设计者在创建 1.0 版本时缺乏远见而承受痛苦。

有些语言对参数化类型采用了更简洁、影响更小的实现方法。不难想象，这样一种语言有可能成为 Java 的接班人，因为它完全采用了 C++ 对待 C 的方式：站在巨人的肩膀上，并看得更远。

在不少讨论中能听到这样的声音：“C++ 是一门设计拙劣的语言。”我则认为理解 C++ 和 Java 做出的各种决策有助于站在更高的位置看待问题。

如同任何人类语言一样，Java 提供了一种表达概念的方式。如果使用得当，随着问题变得更庞大更复杂，这种表达工具将会比别的可供选择的语言更为简单、灵活。

曾几何时，C++ 是编程语言界的“皇冠”，人们认为会永远如此。很多人也这么看 Java，但由于 JVM 的缘故，Java 已经使自己可以被轻而易举地替换掉了。现在，任何人都可以创建一门新的语言，并在短时间内使其像 Java 一样高效运行。但在以前，对于一门新的语言来说，大部分开发时间往往花在实现正确、高效的编译器上。

在我写作本书时，Java 是世界上首屈一指的编程语言。然而 Java 终将老去，就像 C++ 那样，衰退到只会在某些特殊场合用到（甚至只用于支持遗留代码，因为 Java 不如 C++ 和硬件结合那么紧密）。但是 Java 无心插柳却已蔚然成荫的真正光辉之处是，它为自己的替代品创造了一条非常平坦的道路，即使 Java 本身已经到了无法再进化的地步。未来的所有语言都应该从中学习：要么创造一种可以不断重构的文化（如 Python 和 Ruby 做到的那样），要么让竞争者可以茁壮成长。

C 语言是低级语言，这会限制你的野心。这些限制使得扩展多线程库看起来合情合理。然而 Java 更宏大的雄心壮志，使得在将低级语言模型直接照搬到高级语言的过程中，很快就暴露出了根基上的问题。这些错配问题体现于 Thread 类中大量方法的弃用，在随后的为并发提供更好抽象的高级库的浪潮中也暴露了出来。

令人惊叹的是，尽管有这么多无法弥补的重大问题，Java 还是发展到了现在的程度。Java 的后续版本已经增加了库以提升并发的抽象水平。事实上，我之前绝没有想到 Java 8 会带来如此大的提升：并行流和 CompletableFuture——这是史诗般的魔法，我还将非常惊讶地看到更多魔法的诞生。

当面临多个可选方案时，先尝试需要最少假设的方案。

你很容易依赖一门语言，并且陷入一种想要用该语言解决一切问题的状态。

由于思维导图中的链接没法截图，按照先后顺序贴在下面：

思维导图是用亿图脑图 MindMaster制作的，之前重度使用了 Xmind 和 WPS，感觉还是亿图这个思维导图软件比较适合我。

本文 GitHub 地址：链接。如果需要思维导图原件，请在 GitHub 私信获取~思维导图学《On Java》基础卷 + 进阶卷