本书汇集了Java编程实践方面的建议、忠告、范例和讨论，本书的组织是一个个独立的课程，每个课程称为实践（PRAXIS），用以讨论特定主题，每个实践按各自独立的方式撰写。本身详细分析了某些设计和编程方面的问题，挑选的依据是编程实践上的有效和高效。Java最被人抱怨的一点是性能，因此本书以最大的篇幅讨论这一主题，使Java代码运行得更高效。
General Techniques
PRAXIS1:
引数以by value方式而非by reference方式传递
所有Java对象都通过object reference被访问，常见的一个误解是java以by reference方式传递引数，
事实上所有引数都以by value方式传递。
比如int参数，在函数内修改了，在调用后并没有修改
而object则不是这样，函数内修改了，调用后也是修改的，若不想这样，可以把object改为不可变的或拷贝object
PRAXIS2:
对不变的data和object references使用final
为了让data或object reference成为不变量（常数），请使用final。注意，final仅仅令object reference
自身成为不变量，并不限制它所指对象的改变。
PRAXIS3:
缺省情况下所有non-static函数都可被覆盖
缺省情况下，所以non-static函数都可以被subclass覆盖，但如果加上关键字final，便可防止被subclass覆盖。
声明某个类为final，就表示这个类的所有函数都是final的，可以阻止它派生子类。
PRAXIS4:
在arrays和Vectors之间慎重选择
arrays
和vectors是常见的容器类（storage classes）。选用它们之前应该先了解它们的功用和特性。
如果超出了array的大小，会报数组越界异常，基本类型的array会自动为数组内的元素赋默认值，而对象数组则是null。而vector长度会自动增长，vector.size()返回的元素的数量，不是固定值，vector的内部实现是array实现的，vector只能容纳对象。
一般来说，array速度更快。
PRAXIS5:
多态优于instanceof
instanceof
的许多用途可以因为改用多态而消失，使用多态，代码将更清晰、更易于扩展和维护。
PRAXIS6:
必要时才使用instanceof
有时我们无法回避使用instanceof。我们应该了解什么情况下必须使用它。
PRAXIS7:
一旦不再需要object references，就将它设为null
不要忽视内存可能带来的问题，尽管有了垃圾回收机制，你仍然需要关注你的代码如何运用内存，如果能够领悟垃圾回收和内存运用细节，你就能够更好的知道何时应该将object references设为null，那将导致高效的代码。
Objects and Equality
PRAXIS8:
区分reference type和primitive type
Java
是面向对象语言，但其操控的东西并非都是对象（objects）。理解reference type和primitive types之间的差异，及它们在JVM中的表述，会使你在运用它们时得以做出明智的选择。
PRAXIS9:
区分==和equals()
==
用来测试基本型别的相等性，亦可判定两个object references是否指向同一个对象，但若要测试
values
（值）或semantic（语义）相等，应使用equals()。
PRAXIS10:
不要依赖equals()的缺省实现
不要不假思索的认定一个class总是会正确的实现出equals()，此外，java.lang.Object提供的equals()大多数时候并非进行你想要的比较。
PRAXIS11:
实现equals()时必须深思熟虑
如果某个class所生的两个对象“即使不占用相同的内存空间，也被视为逻辑上相等”，那么就该为这个class提供一个equals()。
PRAXIS12:
实现equals()时优先考虑使用getClass()
实现equals()时请优先考虑采用getClass()。毕竟，“隶属同一个class下的对象才得被视为相等”是正确实现equals()的一个简明方案。
惟有相同class所产生的对象才可以被视为相等，可以只比较某些关键属性。
PRAXIS13:
调用super.equals()以唤起base class的相关行为
任何base class（除了java.lang.Object）如果实现equals()，其derived class都应该调用super.equals()。
PRAXIS14:
在equals()函数中谨慎使用instanceof
惟有当你考虑允许“一个derived class对象可以相等于其base class对象”时，才在equals()中使用instanceof。使用这项技术前请先弄清楚其影响。
PRAXIS15:
实现equals()时需遵循某些规则
撰写equals()并非那么直观，如果想要恰当实现出equals()，请遵循某些规则。
1.
如果某个class的两个对象即使占据不同的内存空间，也可被视为“逻辑上相等”的话，那么你得为这个class提供一个equals()。
2.
请检查是否等于this。
3.
比较这个class中的相关属性，以判断两个对象是否相等。
4.
如果有java.lang.Object以外的任何base class实现了equals()，那么就应该调用super.equals()。
Exception Handling
PRAXIS16:
认识“异常控制流”（exception control flow）机制
了解异常控制流程细节，了解这些细微之处有助于你回避问题。
PRAXIS17:
不要忽略异常
一旦异常出现却没有被捕获，抛出异常的那个线程就会中止运行，是的，异常意味错误，永远不要忽略它。
PRAXIS18:
不要隐藏异常
如果处理异常期间又从catch或finally区段抛出异常，原先的异常会因而被隐藏起来，一旦发生这样的事情，就会丢失错误信息，你应当撰写专门负责处理这种情形的代码，将所有异常回传给调用者。
只有一个异常可以传播到外界，可以把所有的异常加入到一个vector内。
PRAXIS19:
理解throws子句的缺点
将一个异常加入某函数的throws子句，会影响该函数的所有调用者。
PRAXIS20:
细致而全面的理解throws子句
任何函数的throws子句应当列出它所传播的所有异常，包括衍生异常型别（derived exception types）。
覆盖一个方法时，throws的异常受到约束
要么不抛出异常，要么和被覆盖方法一样类型的异常，要么是被覆盖方法异常的派生异常。
PRAXIS21:
使用finally避免资源泄漏
不要忽视内存以外的资源，垃圾回收机制不会替你释放它们，请使用finally确保内存以外的资源被释放。
PRAXIS22:
不要从try块中返回
不要从try区段中发出return语句，因为这个函数未必会立即从那儿返回，如果存在finally区段，它就会被运行起来并可能改变回传值。
PRAXIS23:
将try/catch代码块置于循环外
撰写含有异常处理的循环时，请将try和catch区段置于循环外部，在某些实现版本上，这会产生更快的运行代码。
PRAXIS24:
不要将异常用于流程控制
请将异常用于预期行为之外的情况，不要以异常来控制流程，请采用标准的语言流程构件，这样的流程表达会更清晰更高效。
PRAXIS25:
不要每逢出错就使用异常
只有面对程序行为可能出乎意料的情况下才使用异常，“预期中的行为”应使用返回代码来处理。
PRAXIS26:
在构造函数中抛出异常
尽管构造函数并非函数（method），因而不能回传一个值，但构造函数有可能失败，如果它们失败了，请抛出一个异常。
PRAXIS27:
抛出异常之前先将对象恢复为有效状态（valid state）
抛出异常很容易，困难的是“将异常所引发的伤害减到最小”，抛出异常前，应确保“如果异常被处理好，流程再次进入抛出异常的那个函数中，该函数可以成功完成”。
Performance
PRAXIS28:
先把焦点放在设计、数据结构和算法身上
给java带来最大性能提升的办法就是：在设计和算法中使用与语言无关的技术，因此，首先请将你的精力集中在这上面。
PRAXIS29:
不要依赖编译期的优化技术
由java编译器生成的代码，通常不会比你自己撰写的更好，别指望编译器能够多么优化你的源码。
PRAXIS30:
理解运行期的代码优化技术
Java
对性能的大部分努力都围绕着“运行期优化”展开，这种做法有利无弊。
PRAXIS31:
如欲进行字符串的连接，StringBuffer优于String
对于字符串的连接，StringBuffer要比String快许多倍。
PRAXIS32:
将对象的创建成本降至最小
在许多面向对象系统中，“创建对象”意味着高昂的成本，了解成本所在，以及了解“加速对象创建速度”的技术，都可以导致更快速的程序。
PRAXIS33:
谨防未使用的对象
非必要别产生对象，否则会减慢你的程序速度。
PRAXIS34:
将同步（synchronization）减至最低
声明synchronized函数或synchronized区段，会显著降低性能，应该只在对象有所需要时才使用同步机制。
PRAXIS35:
尽可能使用stack变量
stack
变量为JVM提供了更高效的byte code指令序列，所以在循环内重复访问static变量或instance变量时，应当将它们暂时存储于stack变量中，以便获得更快的运行速度。
PRAXIS36:
使用static、final和private函数以促成inlining
以方法体替换方法调用，会导致更快速的程序，如果要令函数为inline，必须先声明它们为static、final或private。
PRAXIS37:instance
变量的初始化一次就好
由于所有static变量和instance变量都会自动获得缺省值，所以不必重新将它们设为缺省值。
PRAXIS38:
使用基本类型（primitive types）使代码更快更小
使用基本类型，比使用其包装类，产生的代码又小又快。
PRAXIS39:
不要使用Enumeration或Iterator来遍历Vector
遍历Vector时，请使用get()函数而非Enumeration或Iterator。这样做会导致更少的函数调用，意味程序速度更快。
PRAXIS40:
使用System.arraycopy()来复制arrays
这个是本机（native）函数，速度更快。
PRAXIS41:
优先使用array，然后才考虑Vector和ArrayList
如果你需要Vector的功能但不需要它的同步特性，可改用ArrayList。
PRAXIS42:
尽可能复用（reuse）对象
复用现有对象，几乎总是比创建新对象更划算。
PRAXIS43:
使用延迟求值（lazy evaluation）
如果某个成本高贵的计算并非一定必要，就尽量少做，使用懒加载技术避免那些永远不需要的工作。
PRAXIS44:
以手工方式将代码优化
由于Java编译器在优化方面的作为甚少，为了生成最佳byte code，请以手工方式将你的源码优化。
PRAXIS45:
编译为本机代码（native code）
编译为本机代码，通常可以获得运行速度更快的代码，但你却因此必须在各种不同的本机方案中取舍。
Multithreading
PRAXIS46:
面对instance函数，synchronized锁定的是对象（object）而非函数（method）或代码
关键字synchronized锁定的是对象，而非函数或代码，一个函数或程序区段被声明为synchronized，并不意味同一时刻只能由一个线程运行它。
PRAXIS47:
弄清楚synchronized statics函数与synchronized instance函数之间的差异
两个函数被声明为synchronized，并不就意味它们是“多线程安全”，对instance函数或object reference同步化，与对static函数或class literal（字面常数）同步化相比，得到的lock全然不同。
PRAXIS48:
以private数据（field）+相应的访问函数（accessor）替换public/protected数据
如果没有适当保护你的数据，用户便有机会绕过你的同步机制。
PRAXIS49:
避免无谓的同步控制
一般情况下请不要同步化所有函数，同步化不仅造成程序缓慢，并且丧失了并发（concurrency）的可能，
请采用“单对象多锁”技术以允许更多并发动作。
PRAXIS50:
访问共享变量时请使用synchronized或volatile
不可切割（原子化，atomic）操作并非意味“多线程安全”，JVM实现品被允许在私有内存中保留变量的工作副本，这可能会产生陈旧数据，为避免这个问题，请使用同步化机制或将变量声明为volatile
PRAXIS51:
在单一操作中锁定所有用到的对象
同步化某一函数，并不一定就会使其成为“多线程安全”，如果synchronized函数操控着多个函数，而它们并不都是此函数所属class的private instance data，那么你必须对这些对象自身也进行同步化。
PRAXIS52:
以固定而全局性的顺序取得多个locks，以避免死锁（deadlock）
当你同步化多个对象，请以固定、全局性的顺序获得locks，以避免死锁。
PRAXIS53:
优先使用notifyAll()而非notify()
notify()
只唤醒一个线程，要想唤醒多个线程，请使用notifyAll()。
PRAXIS54:
针对wait()和notifyAll()使用旋锁（spin locks）
当你等待条件变量时，请总是使用旋锁确保正确结果。
PRAXIS55:
使用wait()和notifyAll()替换轮询循环（polling loops）
将所有polling loops替换为使用wait()、notify()和notifyAll()的spin locks（旋锁），spin locks直观而高效，polling loops则慢很多倍。
PRAXIS56:
不要对上锁对象（locked object）的object reference重新赋值
当一个对象被锁定，有可能其他线程会因同一个object lock而受阻（blocked），假如你对上锁对象的object reference重新赋值，其他线程内悬而未决的那些locks将不再有意义。
PRAXIS57:
不要调用stop()或suspend()
不要调用stop()或suspend()，因为它们可能导致数据内部混乱，甚至引发死锁。
PRAXIS58:
通过线程之间的协作来中止线程
你不应该调用stop()，如欲安全地停止线程，必须要求它们相互协作，才能姿态优雅的中止。
Classes and Interfaces
PRAXIS59:
运用interfaces支持多重继承
当你想要支持interface的单一继承或多重继承，或想要实现一个标识型的interface时，请使用interfaces。
PRAXIS60:
避免interfaces中的函数发生冲突
没有任何办法能够阻止两个interfaces使用同名的常数和函数，为了避免可能的冲突，应当小心命名常数和函数。
PRAXIS61:
如需提供部分实现（partial implementation），请使用抽象类（abstract classes）
使用abstract class来为一个class提供部分实现，这些实现很可能对derived class是共通的。
PRAXIS62:
区分interface、abstract class和concrete class
一旦正确理解interface、abstract class和concrete class的差异，你就可以在设计是编码时做出正确的选择。
PRAXIS63:
谨慎定义和实现不可变类（immutable classes）
如果你希望对象内容永远不被改动，请使用不可变对象（immutable object），这种对象自动拥有“多线程安全性”。
PRAXIS64:
欲传递或接收可变对象（mutable objects）的object references时，请使用clone()
为了保证immutable objects，你必须在传入和回传它们时对它们施行clone()。
PRAXIS65:
使用继承或委托（delegation）来定义不可变类（immutable classes）
使用immutable interface、common interface或base class，或是immutable delegation classes，来定义immutable classes。
PRAXIS66:
实现clone()时记得调用super.clone()
当你实现一个clone()，总是应该调用super.clone()以确保产生正确的对象。
PRAXIS67:
别只依靠finalize()清理non-memory（内存之外）的资源
你不能保证finalize()是否被调用，以及何时被调用，因此，请专门实现一个public函数来释放内存以外的资源。
PRAXIS68:
在构造函数内调用non-final函数时要小心
如果一个non-final函数被某个derived class覆盖，在构造函数中调用这个函数可能会导致不可预期的结果。