Effective java 中文版（第2版）读后感精选10篇
《Effective java 中文版（第2版）》是一本由Joshua Bloch著作，机械工业出版社出版的平装图书，本书定价：52.00元，页数：287，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
《Effective java 中文版（第2版）》读后感(一)：fundmental→advanced
java书籍如core Java经常分两册，上册为基础fundmental，下册为advanced。上册讲编程的基本概念，下册谈被升级的概念（如泛型对于Object，try是某种不判断的if，并发是循环的横向扩展，集合是某种高级的数组等等）。这类书给人的感觉是概念的任意组合，正交化，什么都可以做。
而本书所说的就是希望你用高级的概念的使用去避免基本概念使用的一些弊端，告诉你怎么做更好，什么样的做法可以避免。如书中有推荐使用工厂方法何时替代构造方法，集合何时优于数组，包装类与基本类的比较，ThreadLocal的由来等等。
看完一遍记不住，随手翻翻，翻几次，每次记几条。
《Effective java 中文版（第2版）》读后感(二)：作者很牛
本想给这本书4星的，因为感觉没有Scott Meyers的《Effective C++》、《More Effective C++》、《Effective STL》系列写得好。考虑到Java学习上只此一本《Effective Java》还是给5星吧。毕竟这本书也还是很值得一读的！
本书作者Joshua Bloch是Google公司首席Java架构师。他也是JDK5集合包的设计者，看JDK源代码时经常可以看到他的名字。此外，他还和人合写了经典的《Java并发实践》。
抄录一些笔记，空白的条目表示没看明白，以后有新的理解再补充。
第一章 引言
一， 代码应该被重用，而不是被拷贝。
第二章 创建和销毁对象
一，考虑用静态工厂方法代替构造器
ublic static Boolean valueOf(boolean b) {
return b ？ Boolean.TRUE : Boolean.FALSE;
}
静态工厂方法能够为重复的调用返回相同的对象。
静态工厂惯用名称：valueOf, of, getInstance, newInstance, getType, newType.
二, 遇到多个构造器参数时要考虑用builder模式
三，用私有构造器或者枚举类型强化Singleton属性
1，public class Elvis {
ublic static final Elvis INSTANCE = new Elvis();
rivate Elvis() { .... }
ublic void leaveTheBuilding() {...}
}
2, public class Elvis {
rivate static final Elvis INSTANCE = new Elvis();
rivate Elvis() { ... }
ublic static Elvis getInstance() {
return INSTANCE;
}
ublic void leaveTheBuilding() { ... }
}
3, 单元素的枚举类型已经成为实现Singleton最佳方法
ublic enum Elvis {
INSTANCE;
ublic void leaveTheBuilding() { ... }
}
四，通过私有构造器强化不可实例化的能力
只包含静态方法和静态域的工具类(utility class)实例对它没任何意义，只要让这个类构造器私有就可以保证不会被实例化。
ublic class UtilityClass {
rivate UtilityClass() {
throw new AssertionError();
}
.....
}
副作用：这个类不能被继承。所有的构造器都必须显示或隐式地调用超类的构造器。
五，避免创建不必要的对象
构造器在每次被调用时都会创建一个新的对象。可以使用静态工厂方法代替构造器，以避免创建不必要的对象。例：Boolean.valueOf(String)。
静态初始化，只需初始化一次。
延迟初始化。
六，消除过期的对象引用
只要是类是自己管理内存，程序员就应该警惕内存泄漏。
七，比用使用终结方法
终结方法(finalizer)通常是不可以预测的，也是很危险的。终结方法的缺点在于不能保证会被及时地执行。
在C++中，析构器是回收一个对象所占资源的常规方法。Java中，一般用try-finally完成类似的工作。
第三章 对于所有对象都通用的方法
八，覆盖equals时请遵守通用约定
==比较的是引用，equals比较的是值！
九，覆盖equals时总要覆盖hashcode
@Override public boolean equals(Object O) { ... }
@Override public int hashCode() { ... }
相等的(equals)的对象必须具有相等的hash code。不相等的两个对象，hash code有可能相等。
Eclispe提供了代码生成工具(Source->Generates hashCode() and equals()...)
十，始终要覆盖toString
@Override public String toString() { ... }
十一，谨慎地覆盖clone()方法
ublic interface Cloneable {
}
如果一个类实现了Cloneable，Object的clone方法就会返回该对象的逐域拷贝，否则就会抛出CloneNotSupportedException.
clone()就是另一个构造器；你必须确保它不会伤害到原始的对象，并确保正确地创建被克隆对象中的约束条件。(深度拷贝,deep copy）
无需调用构造器就可以创建对象。
协变返回类型(covariant return type),override方法的返回类型可以是被覆盖方法返回类型的子类型。
所有实现Cloneable接口的类都应该用一个公有方法覆盖clone。此方法首先调用super.clone(),然后clone自身域。
@Override public Stack clone() {
try {
tack result = (Stack)super.clone();
result.elements = elements.clone();
return result;
} catch (CloneNotSupportedException e) {
throw new AssertionError();
}
}
另一个实现对象拷贝的办法是提供一个拷贝构造器或拷贝工厂：
ublic Yum(Yum yum); copy ctor
ublic static Yum newInstance(Yum yum); copy factory
十二，考虑实现Comparable接口
类实现了Comparable接口，就表明它的实例具有内在的排序关系。
ublic interface Comparable<T> {
int compareTo(T t);
}
当该对象小于、等于或大于指定对象的时候，分别返回一个负整数、零或正整数。
第四章 类和接口
十三， 使类和成员的可访问性最小化
rivate, package-private, protected, public
十四，在公有类中使用访问方法而非公有域
十五，使可变性最小化
十六，组合优先于继承
实现继承(implementation inheritance), 接口继承(interface inheritance)
组合(composition), 转发方法(forwarding method)
包装类(wrapper class)-->Decorator模式
十七，要么为继承而设计并提供文档说明，要么就禁止继承
十八，接口优于抽象类
抽象类允许包含某些方法的实现；接口不允许。
为实现抽象类定义的类型，类必须成为抽象类的一个子类，Java只允许单继承；可以implement多个接口
十九，接口只用于定义类型
静态导入(static import)：JUnit，ass ertEquals()
二十，类层次优于标签类
二十一，用函数对象表示策略
class StringLengthComparator {
ublic int compare(String s1, String s2) {
return s1.length() - s2.length();
}
}
tringLengthComparator没有域是无状态的，因此非常适合成为Singleton。
class StringLengthComparator {
rivate StringLengthComparator() { }
ublic static final StringLengthComparator INSTANCE = new StringLengthComparator();
ublic int compare(String s1, String s2) {
return s1.length() - s2.length();
}
}
ublic interface Comparator<T> {
ublic int compare(T t1, T t2);
}
Arrays.sort(stringArray, new Comparator<String>() {
ublic int compare(String s1, String s2) {
return s1.length() - s2.length();
}
};
可以将函数对象存储到一个私有的静态final域中，并重用。
class Host {
rivate static class StringLengthComparator implements Comparator<String>, Serializable {
ublic int compare(String s1, String s2) {
return s1.length() - s2.length();
}
}
ublic static final Comparator<String> STRING_LENGTH_COMPARATOR = new StringLengthComparator();
.....
}
函数指针的主要用途就是实现策略(Strategy)模式。Java中声明一个接口表示策略，并且为每个具体策略声明一个实现了该接口的类。例:Arrays.sort(array, comparator);
二十二，优先考虑静态成员类
嵌套类有四种：静态成员类，非静态成员类，匿名类，局部类。
非静态成员类的每个实例都隐含着与一个外围实例相关联
匿名类一种常见用法是动态地创建函数对象；
另一种用法是创建过程对象，比如Runnable,Thread或者TimerTask实例；
第三种常见的用法是在静态工厂方法的内部。
第五章 泛型
二十三，不要在新代码中使用原生态类型
二十四，消除非受检警告
@SuppressWarnings("unchecked")
二十五，List优先于数组
二十六，优先考虑泛型
二十七，优先考虑泛型方法
二十八，利用有限制通配符来提升API的灵活性
二十九，优先考虑类型安全的异构容器
第六章 枚举和注解
三十，用enum代替int常量
三十一，用实例域代替序数
ublic enum Ensemble {
OLO(1), DUET(2), TRIO(3), QUARTET(4);
rivate final int numberOfMusicians;
Ensemble(int size) { this.numberOfMusicians = size; }
ublic int numberOfMusicians() { return numberOfMusicians; }
}
三十二，用EnumSet代替位域
三十三，用EnumMap代替序数索引
三十四，用接口模拟可伸缩的枚举
三十五，注解优先于命名模式
三十六，坚持用Override注解
三十七，用标记接口定义类型
标记接口(marker interface)是没有包含方法声明的接口。例：Serializable
第七章 方法
三十八，检查参数有效性
在方法体得开头处检查参数。
三十九，必要时进行保护性拷贝
四十，谨慎设计方法签名
谨慎选择方法名；避免过长参数列表；
参数类型优先使用接口而非具体类；
对于boolean参数，优先使用两个元素的枚举类型：
ublic enum TemperatureScale { FAHRENHEIT, CELSIUS }
四十一，慎用重载
overload方法的选择是静态的，overridden方法的选择是动态。
四十二，慎用可变参数
四十三，返回零长度的数组或者集合而不是null
Collections.emptySet(), Collections.emptyList(), Collections,emptyMap(0
四十四，为所有导出的API元素编写文档注释
第八章 通用程序设计
四十五，将局部变量的作用域最小化
四十六，for-each循环优先于传统的for循环
for (Iterator i = c.iterator(); i.hasNext(); ) {
doSomething((Element)i.next());
// i.remove();
}
ublic interface Iterable<E> {
Iterator<E> iterator();
}
三种情况下无法使用for-each循环:过滤，转换，平行迭代。
四十七，了解和使用类库
java.lang.*, java.util.*, Collections Framework
四十八，如果需要精确的答案，请避免使用float和double
igDecimal
四十九，基本类型优先于装箱类型
永远不要用==做相等测试！Object.equals(object);
五十，如果其他类型更适合，则避免使用字符串
五十一，需要连接字符串时，用StringBuilder代替String
五十二，优先使用接口而非类来引用对象
五十三，接口优先于反射机制
五十四，谨慎地使用本地方法
五十五，谨慎地进行优化
必须在设计时考虑性能问题；使用性能剖析工具探测性能瓶颈
五十六，遵守普遍接受的命名惯例
第九章 异常
五十七，只针对异常的情况才使用异常
五十八，对可恢复的情况使用受检情况，对编程错误使用运行时异常
五十九，避免不必要地使用受检的异常
六十，优先使用标准的异常
六十一，抛出与抽象相对应的异常
六十二，每个方法抛出的异常都要有文档
六十三，在细节消息中包含能捕获失败的信息
六十四，努力使失败保持原子性
六十五，不要忽略异常
第十章 并发
六十六，同步访问共享的可变数据
六十七，避免过度同步
六十八，executor和task优先于线程
六十九，并发工具优先于wait和notify
七十，线程安全性的文档化
七十一，延迟延迟初始化
七十二，不要依赖于线程调度器
七十三，避免使用线程组
第十一章 序列化
七十四，谨慎地实现Serializable接口
七十五，考虑使用自定义的序列化形式
七十六，保护性地编写readObject方法
七十七，对于实例控制，枚举类型优先于readResolve
七十八，考虑用序列化代理代替序列化实例
《Effective java 中文版（第2版）》读后感(三)：每个java程序员的案头应该有一本
读第一版已经是好几年前的事儿了, 现在想起来也没什么印象, 也没什么收获, 估计那会儿刚接触java, 还是个菜鸟, 很多东东都不甚了解. 虽然一直在用java, 不过大部分都是用一些很常见的东西, 其实java还有很多细节和技巧值得我们去发掘和实践, 而这些内容却能真正体现一个人的Java水平. 看第二版收获非常多, 应该算是我看过的java书中最好的一本, 里面有不少使用Java的技巧, 并且可以在实际工作中大量采用, 应该作为桌面上常备的参考工具书.
这本书很少去讲java的一些用法, 因此针对的用户群不是java的初哥或菜鸟. 而更多的在讲为什么不能这样做, 为什么最好那样做, 解释原因, 提供参考和建议.
--------------我是读书笔记的分割线------------------
对于代码来说, 清晰和简洁是最重要的.
代码应该被重用, 而不应该被拷贝
更多内容:http://macrochen.iteye.com/blog/1113031
《Effective java 中文版（第2版）》读后感(四)：Effective Java - 干货满满
每种语言都有一个“Effective guide”，对于Java，那就是这本《Effective Java》。
这是一本实用至上的书，78条建议，满满的干货。每一条都说明了为什么最好这样。这些经验，都是对大量的程序项目进行反思时逐渐形成的。对于Java这种极为健全乃至有点过于丰满的语言，这样一本“实用手册”非常有帮助。
写Java程序时，手边最好放着这本书，对于当前写的东西，随手查阅一下，看看自己想的和书中建议的是否一样，如果不一样，为什么。
不足之处，一是出现了很多次“单行循环不加括号”的情况，对于这类讲“实效”的书，不可原谅；二是中文翻译水平较低，大量生涩牵强的翻译，让人怀疑根本就是直接把Google翻译的结果拿来了。
《Effective java 中文版（第2版）》读后感(五)：第一读后感：
1. Java程序员分两种，读过<Effective Java>的和没读过的，严格的来说，没读过的不算是Java程序员。
2. 书组织的不错，很适合在碎片时间看上一两条，然后再慢慢回味；
《Effective java 中文版（第2版）》读后感(六)：《Effective Java》中学到的思想
序言
零散地读完《Effective Java》（中文版第二版），真心觉得这是一本经典书籍。现在想写一下读完这本书的整体收获，而不是涉及到书中某一个具体的知识点。
收获
在重点或疑问的地方，做出标记和注释
在读《Effective Java》时，对于前10条建议，我并没有理解得很深刻，因为我只是简单地拿笔在书上划下重点的句子而已。我也感觉到了问题，后来在重点或疑问的地方，做出标记和注释，对于问题的理解提升很大。
虽然这是一个很愚蠢的问题——连小学一年级的学生都知道，但是我却刚刚体会到这样做的好处。比如我在看到第12条考虑实现Comparable接口一节时，首先问了自己一个问题：如何使用Comparable接口？
后来发现Comparable接口采用了策略模式的设计模式，进一步分析了策略模式。看到P54中间的一句话：依赖于比较关系的类包括有序集合类TreeSet和TreeMap，以及工具类Collection和Arrays，它们内部包含有搜索和排序算法。我就问了自己几个问题：这些工具类比如Arrays的sort，使用的是什么算法？Comparable接口是如何与Arrays的sort方法结合在一起，进而通过传入不同的Comparable接口，来实现Arrays的不同sort排序的？
之后我发现Arrays.sort会根据不同的类型，采取不同的排序方法。对于基本类型，会采用调优的快速排序；对于对象类型，会采取改进的归并排序。然后我就会问自己：为什么对于基本类型和对象类型，要采取不同的排序方法呢？快速排序的调优，体现在哪里？归并排序的改进，又体现在哪里？在查看源代码的基础上，我又发现JDK 7采用了一种Dual-Pivot Quicksort的快排方法，就会思考这个算法好在哪里？
在查看源代码的过程中，我发现注释中有个API的设计者是Josh Bloch，我就Google了一下。我才注意到他就是这本书的作者啊！我才知道Java的集合框架就是他设计的，才知道译者序里面的介绍，都是关于他的……我看书很少注意作者，这个习惯可不好。进一步Google，我发现了他的Twitter，我是不是应该关注他？那还有哪些Java领域和计算机领域的国外、国内牛人，我应该关注一下？如果在使用Java的过程中，连它的开发者及演变过程都不知道……通过问自己几个问题，我一下子就打开了一个全新的世界+_+
深入思考
忘记从哪里看见过一句话，大意是：只有了解全部的真相，才能获得全部的自由——编程领域更是如此。就好比我读《Effective Java》，如果只是简单阅读第12条考虑实现Comparable接口一节，想必几分钟就草草略过了。但是我获得了什么？是能够和别人吹嘘说：我把《Effective Java》看了3遍，《Java编程思想》看了5遍？即使看10遍又有什么意义呢？如果我不花费时间，问自己几个问题，亲自去研究一下Comparable接口，那么我不会知道JDK底层的实现细节，我并没有了解全部的真相，每次使用时都会有个疑问：咦，Arrays.sort是怎么通过对象的Comparable接口，实现不同的排序的？如果不去解决自己的疑惑，那么问题只会越来越多、越来越严重。
套用M·斯科特·派克《少有人走的路——心智成熟的旅程》中的一句话（大意）：逃避问题所带来的痛苦，甚至比问题本身所带来的痛苦，更为严重；问题永远不会自动消失，直到我们去直面问题、解决问题。我可能是有些过于类比了，但是如果关于编程的疑问，我们不去自己解决并亲自弄明白，那么我们就是在逃避问题。
深入思考具有许多好处（自己浅显的总结，欢迎大家留言讨论）：
1. 不会每次遇到问题，就想一次：这个功能是怎么实现的？这次没时间，还是以后再研究吧！
2. 大脑的容量是有限的，这些问题只有在真正解决之后，才不会占用大脑的容量。《Head First》系列在引言部分，提出的第一条建议就是：慢一点，你理解的越多，需要记住的就越少。
3. 在我们完全理解一个问题后，下次再遇到同样的问题，只会更加深对于这个问题的思考，而不是那个老问题（这个功能是怎么实现的）。
4. 增加自信，获得自由。
深入思考并不会占用太多时间，我们离大部分真相都只有一步的距离。而且重要的是思考的深度，而且这样思考能够带来很大的满足感。至少我在读《Effective Java》时，就是这个感觉——一点也不觉得累，通过不断问自己问题，获得了很多很多知识，并且一直处于兴奋状态。
优秀的框架（习惯），是指在无意识中也不会犯错
在第45条将局部变量的作用域最小化一节中（中文第二版P182），作者为了说明为什么将作用域最小化，for循环比while循环好时，列举出了一个代码片段，包含一个“剪切——粘贴”错误：本来是要初始化一个新的循环变量i2，却使用了旧的循环变量i。代码仍然能够通过编译，运行的时候也不会抛出异常，但是实现的功能却是错误的。如果使用了for-each形式，就会从根本上避免这种无意识的错误。
作者是Java API的设计者，考虑得不仅仅是如何才能够使Java API实现效率更高，还包括如何让客户端更具灵活性、如何从架构的设计上，减少客户端犯错误的机会。这完完全全也适合每一个开发者。进一步思考，在现实中也是一样啊！我曾经看过一篇文章，讨论如何通过优秀的习惯，减少无意识中犯错误的机会。
最重要的是思想，而不是实现细节
细节很重要，但是书籍、框架乃至Java的设计思想，才是最重要的（所以Bruce Eckel的《Thinking in Java》才会翻译成《Java编程思想》？）。在阅读源码时，不仅仅是语义上的理解，考虑一下为什么要这么实现这个功能？这样实现有什么好处？它的适用场景有哪些？是否还能够改进？哪些思想我能够借鉴到平时的工作和生活中？
李笑来老师的一篇文章中有这样两段话：
他们在读书的时候，不仅仅是文字以及文字所阐述的道理，更多注意到的是作者的思考方式。作者的“思考方式”与自己的“思考方式”有什么不同？如果作者的“思考方式”更好，自己应该如何调整？
一本概率论读完，大多数人就是考个试也不一定及格，而另外的极少数人却成了科学家——因为他们改良了自己的思考方式，从此可以“像一个科学家一样思考”……
如果我要成为Java专家，我就应该去阅读JDK源码，因为这是Java专家及天才思想的结晶。我更应该去思考：他们为什么这样设计？他们的设计思想是什么？要像一个Java专家一样思考~
抓住思想的好处：
1. 提纲挈领，能够忽略不重要的细节，将注意力集中在重要的地方（所谓的二八法则）。
2. 阅读速度的提升。可以快速略过不重要的细节，我的阅读效率大大提升。
3. 能够看清全局，对整体有清晰的把握。
4. 可以改良自己的思考方式，使得我们像一个科学家一样思考、像一个Java专家一样思考。
总结
我在读完《Effective Java》后，发觉《Java编程思想》这本书需要重新读一遍了，因为以前只是简单地划了一下重点句子而已。当然，除了一个人潜心研读之外，还需要多和他人讨论和总结。
《Effective java 中文版（第2版）》读后感(七)：内容较好，纸质较差
先说内容，翻译的java语言工具书，属于高阶教材。我们团队的新人几乎人手一册。虽然解决程序问题时抱佛脚有些滑稽，但是调通程序这个挠头的场合，有几次助手的确是查书找见的盲点。
纸质的差，有点离谱。薄不说，平滑度也不好，背后的字有些透过来。因为这种程序语言书过了十年注定沦为废纸，所以也犯不着计较太甚。
定价算比较贵的。我们是去年在养育巷和道前街交叉口的文化市场买的，砍了砍三折，也就很满意地在一个书摊包圆了他们的最后五册。这种折扣是不是盗版？不知道。看上去倒不象。机械工业出版社的程序书大多用纸都是这样的。再说好像也没人盗印这种电脑书。
书没有锁线，不过胶上的厚实，估计用两年还不致于散成烂纸片
《Effective java 中文版（第2版）》读后感(八)：书是好书，但是翻译实在不敢恭维
书是好书，但是翻译简直不堪卒读，有些地方我估计译者可能自己现在都看不懂。英语水平可以的话还是建议和英文版对比着读，我对比的时候就发现几个容易让读者迷惑的地方。比如在第 37 条的最后一段：
原文是：
“In a sense, this item is the inverse of Item 19, which says, "If you don't want to define a type, don't use an interface." To a first approximation, this item says, "If you do want to define a type, do use an interface.”
译者的翻译是：
“从某种意义上说，本条目与第 19 条中 ‘如果不想定义类型就不要使用接口’ 的说法相反。本条目最接近的意思是说：如果想要定义类型，一定要使用接口。”
此处将 inverse 翻译成 “否命题” 就会比翻译成 “相反” 妥当一点。因为中文语境中，“相反” 就是意义相反，但是这里并没有否定 19 条中的说法，而是补充和加强。而 “否命题” 则能准确还原原文，因为一个命题的否命题其条件和结论都和原命题相反，但表达的意义不一定和原命题相反。
又比如 37 条的倒数第四段，有一句话：
原文是：
“If the marker applies only to classes and interfaces, ask yourself the question, Might I want to write one or more methods that accept only objects that have this marking？ If so, you should use a marker interface in preference to an annotation.”
而译文是：
“很显然，如果标记是应用到任何程序元素而不是类或者接口，就必须使用注解，因为只有类和接口可以用来实现或者扩展接口。如果标记只应用给类或者接口。就要问自己：我要编写一个还是多个只接受有这种标记的方法呢？如果是这种情况，就应该优先使用接口而非注解。”
那个问句其实想表达的意思是：“我是否想要写一个或者多个【只接受【有这种标记】（对象的定语）的对象】（方法的定语）的方法呢？”。
这是一个普通的疑问句，译者却把它翻译成选择疑问句了，而后面却假设 “如果是这种情况”。那么，这种情况指代的是哪种情况呢？想必此时读者是云里雾里了。由此看来前面的应该是普通疑问句而非选择疑问句。
说了这么多，就是想劝读者们，如果英语水平可以的话，最好选择读英文版，或者两种对比着读，否则花了时间还不一定能领悟到本书的 Effective 之处。
《Effective java 中文版（第2版）》读后感(九)：翻译错误随手记
首先声明，这本书的中文翻译大体上还是过得去的，大方向上没问题。
----------------------------分割线----------------------------
1. p129
翻译：Java的枚举类型是功能十分齐全的类，功能比其他语言中的对等物要更强大得多，Java的枚举本质上是int值。
原文：Java's enum types are full-fledged classes, far more powerful than their counterparts in these other languages, where enums are essentially int values.
这里明明说的是其他语言中的枚举本质上是int值嘛。我晚上睡觉前还在琢磨，既然Java的枚举本质是int，那么还费那么大劲干嘛。。。
2. p129
翻译：它们是单例（Singleton）的泛型化（见第3条）
原文：They are a generalization of Singletons (Item 3)
这里的“泛型化”属于明显的用词不当，非常容易误导。泛型化的英文应该叫generification （见书中第26条）。枚举其实是单例的一种推广形式，本质上是有限个受控实例。关于这点我昨天睡觉前不用琢磨就明白了 ：）
3. p136
翻译：一般来说，枚举会优先使用comparable而非int常量。
原文：Enums are, generally speaking, comparable in performance to int constants.
这句就是纯粹瞎胡闹的翻译了。正确的翻译应该是“一般来说，枚举在性能方面不比int常量差”。