practical java读书目录笔记

《practical java》这本书里讲了很多实践性很强的经验，最近在读这本书，以前看过一遍没记下什么内容，现在再看一遍，因为有一点印象了，所以我想以后看着书的目录我还是能学习到很多东西，故把书的目录拿出来给大家分享，当然也只有几本书的目录是可以当作读书笔记的了。哈哈！！

Note：补充下TW术语和CN术语对照表

函式 ==== 函数

物件====对象

引数====参数

实作====实现

多型====多态

呼叫====调用

建构式===构造函数

 

一般技术（General Techniques）

 实践1：参数是以by value而非by reference方式传递
 所有Java 对象都通过object reference被访问。常见的一个误解是Java以by reference方式传递参数。事实上所有惨数都以by value方式传递。
 
实践2：对不变的data和object reference使用final
 为了让data或object reference成为不变量，请使用final。注意，final仅仅令object reference自身成为不变量，并不限制它所指对象的改变。

 实践3：缺省情况下所有non-static函数都可被覆写（overridden）
缺省情况下，所有non-static函数都可以被subclass覆写。但如果加上关键字final，便可防止被subclass覆写。

 实践4：慎重选择arrays和Vectors
 arrays和vectors是常见的容器类别（storage classes）。选用它们之前应该先了解它们的功用和特性。

 实践5：多态（polymorphism）优于instanceof
 instanceof的许多用途可以因为改用多态而消除之。使用多态，程式码将更清晰、更易於扩展和维护。

 实践6：必要时才使用instanceof
 有时我们无法回避使用instanceof。我们应该了解什麽情况下必须使用它。

 实践7：一旦不再需要object references，就将它设为null
 不要忽视记忆体可能带来的问题。尽管有了垃圾回收机制（garbage collection），你仍然需要关注你的程式码如何运用记忆体。如果能够领悟垃圾回收机制和记忆体运用细节，你就能够更好地知道何时应该将object references设为null，那将导致高效的程式码。
 
对象与相等性（Objects and Equality）

 实践8：区分reference type和primitive type
 Java是面向对象的，但其操控的东西并非都是物件（objects）。理解reference type和primitive types之间的差异，及它们在JVM中的表述（representation），会使你在运用它们时得以做出明智的选择。

 实践9：区分 == 和equals()
 == 用来测试基本型别的相等性，亦可判定两个object references是否指向同一个object。若要测试values（值）或semantic（语意）相等，应使用equals()。

 实践10：不要依赖equals()的预设实作（default implementation）
 不要不假思索地认定一个class总是会正确实作出equals()。此外，java.lang.Object提供的equals()大多数时候并非进行你想要的比较。

 实践11：实作equals()时必须深思熟虑
 如果某个class的两个objects「即使不占用相同的记忆体空间，也被视为逻辑上相等」，那麽就该为这个class提供一个equals()。

 实践12：实作equals()时优先考虑使用getClass()
 实作equals()时请优先考虑采用getClass()。毕竟，「相同class下的objects才得被视为相等」是正确实作equals()的一个清晰简明的解决方案。

 实践13：呼叫base class（基础类别）的super.equals()
 任何base class（除了java.lang.Object）如果实作equals()，其derived class都应该呼叫super.equals()。

 实践14：在equals()函式中谨慎使用instanceof
 唯有当你考虑允许「一个derived class object可以相等於其base class object」时，才在equals()中使用instanceof。使用这项技术前请先弄清楚其影响。

 实践15：实作equals()时需遵循某些规则
 撰写equals()并非那麽直观浅白。如果想要恰当地实作出equals()，请遵循某些规则。

 异常处理（Exception Handling）

 实践16：认识「异常控制流」（exception control flow）机制
 让自己谙晓异常控制流程细节。了解这些细微之处有助於你回避问题。

 实践17：绝对不可轻忽异常（Never ignore an Exceptions）
 一旦异常出现却没有被捕获，抛出异常的那个执行绪（thread）就会中止运行。是的，异常意味错误，永远不要忽略它。

 实践18：千万不要掩盖异常（Never hide an Exceptions）
 如果处理异常期间又从catch或finally区段抛出异常，原先的异常会因而被隐蔽起来。一旦发生这样的事情，就会丢失错误资讯。你应当撰写专门负责处理这种情形的程式码，将所有异常回传给呼叫者。

 实践19：明察throws子句的缺点
 将一个异常加入某函式的throws子句，会影响该函式的所有呼叫者。

 实践20：细致而全面地理解throws子句
 任何函式的throws子句应当列出它所传播的所有异常，包括衍生异常型别（derived exception types）。

 实践21：使用finally避免资源泄漏（resource leaks）
 不要忽视记忆体以外的资源。垃圾回收机制不会替你释放它们。请使用finally确保记忆体以外的资源被释放。

 实践22：不要从try区块中回返
 不要从try区块中发出return指令，因为这个函式未必会立即从那儿回返。如果存在finally区段，它就会被执行起来并可能改变回传值。

 实践23：将try/catch区块置於回圈（loop）之外
 撰写含有异常处理的回圈时，请将try和catch区块置於回圈外部。在某些实作版本上，这会产生更快的执行码。

 实践24：不要将异常（exceptions）用於流程控制
 请将异常用於预期行为之外的情况。不要以异常来控制流程，请采用标准的语言流程构件（flow constructs），这样的流程表达会更清晰更高效。

 实践25：不要每逢出错就使用异常（exceptions）
 只有面对程式行为可能出乎预料的情境下才使用异常。「预期中的行为」应使用回传码（return codes）来处理。

 实践26：在建构式（constructors）中抛出异常
 尽管建构式并非函式（method），因而不能回传一个值，但建构式有可能失败。如果它们失败了，请抛出一个异常。

 

实践27：抛出异常（exceptions）之前先将object恢复为有效状态
 抛出异常很容易，困难的是「将异常所引发的伤害减到最小」。抛出异常之前，应确保「如果异常被处理好，流程再次进入抛出异常的那个函式中，该函式可以成功完成」。

 效能/效率（Performance）

 实践28：先把焦点放在设计、资料结构和演算法身上
 给Java带来最大效能提升的办法就是：在设计和演算法中使用与语言无关的技术。因此，首先请将你的精力集中於这些上面。

 实践29：不要倚赖编译期程式码优化技术
 由Java编译器生成的码，通常不会比你自己撰写的更好。别指望编译器能够多麽优化你的原始码。

 实践30：理解运行期（runtime）程式码优化技术
 Java效能的大部分努力都围绕着运行期优化展开。这种作法有利有弊。

 实践31：如欲进行字串接合，StringBuffer优於String
 对於字串接合，StringBuffer class要比String class快许多倍。

 实践32：将object的创建成本（creation cost）降至最小
 在许多物件导向系统中，「产生物件」意味着高昂的成本。了解成本所在，以及了解「加速物件产生速度」的技术，都可以导致更快的程式码。

 实践33：慎防未用上的物件（unused objects）
 非必要别产生物件。非必要地产生物件，会减慢你的程式速度。

 实践34：将同步（synchronization）减至最低
 宣告synchronized函式或synchronized区块，会显着降低效能。只在物件需要时才使用同步机制（synchronization）。

 实践35：尽可能使用stack变数
 stack变数为JVM提供了更高效的byte code指令序列。所以在回圈内重复取用static变数或instance变数时，应当将它们临时储存於stack变数中，以便获得更快的执行速度。

 实践36：使用static、final和private函式以允许实施inlining
 以函式本体替换函式呼叫，会导致更快的程式码。如果要令函式为inline，必须先宣告它们为static、final或private。

 实践37：instance变数的初始化只要一次就好
 由於所有static变数和instance变数都会自动获得预设值，所以不必重新将它们设为预设值。

 实践38：使用基本型别（primitive types）使程式码更快更小
 使用基本型别，比使用基本型别外覆类别（wrapper），产生的程式码又小又快。

 实践39：不要使用Enumeration或Iterator来巡访Vector
 巡访Vector时，请使用get函式而非Enumeration或Iterator。这样做会导致更少的函式呼叫，意味程式码会更快。

 实践40：使用System.arraycopy() 来复制arrays
 请使用System.arraycopy() 来复制arrays。那是个原生（native）函式，速度最快。

 实践41：优先使用array，然後才考虑Vector和ArrayList
 如果可能，就使用array。如果你需要Vector的功能但不需要它的同步特性，可改用ArrayList。

 实践42：尽可能复用（reuse）objects
 复用现有物件，几乎总是比产生新物件更划算。

 实践43：使用缓式评估（延迟求值，lazy evaluation）
 如果某个成本高贵的计算并非一定必要，就尽量少做。请使用「缓式评估」
 （lazy evaluation，延迟求值）技术避免那些永远不需要的工作。

 实践44：手工优化（optimize）你的程式码
 由於Java编译器在优化方面的作为甚少，为了生成最佳byte code，请手工优化你的原始码。

 实践45：编译为原生码（native code）
 编译为原生码，通常可以导致执行速度更快的程式码。但你却因此必须在各种不同的原生方案（native solution）中取舍。

 多线程（Multithreading）

 实践46：面对instance函数，synchronized锁定的是物件而非函式或程式码
 关键字synchronized锁定的是物件，而非函式或程式码。一个函式或程式
 区段被宣告为synchronized，并不意味同一时刻只能由一个执行绪执行它。

 实践47：弄清楚synchronized statics与synchronized instance函式之间的差异
 两个函式被宣告为synchronized，并不就意味它们是「执行绪安全」（thread-safe）的。对instance函式或 object reference同步化，与对static函式或class literal（字面常数）同步化相比，得到的lock全然不同

 实践48：以「private资料搭配存取器（accessor）」取代public/protected资料
 如果没有适当保护你的资料，用户便有机会绕过你的同步机制。

 实践49：避免无谓的同步控制（avoid unnecessary synchronization）
 一般情况下请不要同步化所有函式。同步化不仅造成程式缓慢，并且丧失了
 并行（concurrency）的可能。请采用「单物件多锁」技术以允许更多并行。

 实践50：取用共享变数时请使用synchronized或volatile
 不可切割（原子化，atomic）操作并非意味「执行绪安全」。JVM实作品被允许在私有记忆体中保留变数的工作副本。这可能会产生陈旧数值（stale values）。为避免这个问题，请使用同步化机制或将变数宣告为volatile。

 实践51：在单一操作（single operation）中锁定所有用到的objects
 同步化某一函式，并不一定就会使其成为「执行绪安全」的函式码。如果synchronized函式操控着多个objects，而它们并不都是此函式所属class的private instance data，那麽你必须对这些objects自身也进行同步化。

 实践52：以固定而全域性的顺序取得多个locks（机锁）以避免死结（deadlock）
 当你同步化多个物件，请以固定和全域性的顺序获得locks，以避免死结。

 实践53：优先使用notifyAll()而非notify()
 notify()只唤醒一个执行绪。要想唤醒多个执行绪，请使用notifyAll()。

 实践54：针对wait()和notifyAll()使用旋锁（spin locks）
 当你等待条件变数（condition variables）时，请总是使用旋锁（spin locks）以确保正确结果。

 实践55：使用wait()和notifyAll()取代轮询回圈（polling loops）
 将所有polling loops替换为使用wait()、notify()和notifyAll()的spin locks（旋锁）。使用spin locks直观而高效，使用polling loops则慢很多倍。

 实践56：不要对locked object（上锁物件）之object reference重新赋值
 当一个object被锁定，有可能其他执行绪会因同一个object lock而受阻（blocked）。假如你对上锁物件的object reference重新赋值，其他执行绪中悬而未决的那些locks将不再有意义。

 实践57：不要呼叫stop()或suspend()
 不要呼叫stop()或suspend()，因为它们可能导致资料内部混乱，甚至引发死结（deadlock）。

 实践58：透过执行绪（threads）之间的合作来中止执行绪
 你不应该呼叫stop()。如欲安全地停止执行绪，必须要求它们相互协作，才能姿态优雅地中止。
 类别与介面（Classes and Interfaces）

 

类与接口
 实践59：使用interface支援多重继承（multiple inheritance）
 当你想要支援interface的单一继承或多重继承，或者想要实作一个标记式的（marker）interface时，请使用interfaces。

 实践60：避免interfaces中的函式发生冲突
 没有任何办法能够阻止两个interfaces使用同名的常数和函式。为了避免可能的冲突，应当小心命名常数和函式。

 实践61：需要提供部分实作（partial implementation）时，请使用abstract classes
 使用abstract class来为一个class提供部分实作，这些实作很可能对derived class是共通的（都被需要的）。

 实践62：区分interface、abstract class和concrete class
 一旦正确理解了interface、abstract class和concrete class的差异，你就可以在设计和撰码时做出正确的选择。

 实践63：审慎地定义和实作immutable classes（恒常类别）
 如果你希望object的资料永远不被改动，请使用immutable object。这种objects自动拥有执行绪安全性（thread safety）。

 实践64：欲传递或接收mutable objects（可变物件）之object references时，请施行clone()
 为了保证immutable objects，你必须在传入和回传immutable objects时对它们进行clone动作。

 实践65：使用继承（inheritance）或委托（delegation）来定义 immutable classes（恒常类别）
 使用immutable interface、common interface或base class，或是immutable delegation classes，来定义immutable classes（恒常类别）。

 实践66：实作clone()时记得呼叫super.clone()
 当你实作了一个clone()，总是应该呼叫super.clone()以确保产生正确的object。

 实践67：别只是倚赖finalize()清理记忆体以外的（non-memory）资源
 你不能保证finalize()是否被呼叫，以及何时被呼叫。因此，请专门实作一个public函式来释放记忆体以外的资源。

 实践68：在建构式（constructors）内呼叫non-final函式时要当心
 如果一个non-final函式被某个derived class覆写，在建构式中呼叫这个函式可能会导致不可预期的结果。