java编码规范
右括号”) ”与其后面的关键字之间，关键字与其后面的左括号”(”或”{”之间，以及”}”与”{”之间，要以一个空格隔开；除”. ”外，所有二元操作符的前、后要加空格；在逗号后边加一个空格。
示例：
for (int i = 0; i <= 10; i++) {
...
}
double xNorm = y > 0.0 ? (x / y) : x;
一个Java文件代码不宜太长，一般建议500行以内（不包括注释），客户端GUI相关Java文件可以稍长，但超过2000行的程序难以阅读，应该尽量避免。
1.考虑将代表基础数据类型的类声明为final的。
说明：以提高调用效率。
带有final修饰符的类是不可派生的。在Java核心API中，有许多应用final的例子，例如java.lang.String。为String类指 定final防止了使用者覆盖length()方法。另外，如果一个类是final的，则该类所有方法都是final的。java编译器会寻找机会内联 (inline)所有的final方法(这和具体的编译器实现有关)。此举能够使性能平均提高50%。
2. 定义小型的类和方法。
说明：要尽量减少类中的方法数，在能够满足需要的情况下避免再增加多余的方法。一个方法只实现一个功能，不要设计多用途、面面俱到的方法。对于过大的类或方法，要考虑将其重构到更多的类或方法中。
3. 所有的成员都应该是私有的，通过对象方法来访问。
说明：以保证只有成员所属的类才能对它们作变更，从而使对象间的耦合性最小，程序易于维护。
4. 利用多态性来取代”instanceof”。
说明：用”instanceof”来判断对象类型的代码，必须随着可选对象类型的变化而改变，这样的代码是不稳定、不易于维护的。因此要使用多态，避免使用”instanceof”。
5. 用等效的方法替换重复的语句。
说明：代码应该只写一次。对于拷贝粘贴生成的重复代码，必须将其重构到一个方法或类中，来消除它们。
将一般操作重构为一个方法或类，使代码更易于理解和维护，同时可减少测试的工作量。
6. 在控制流结构中使用块语句(即用{}括起来)，而不要用表达式语句。当控制流中只有一个语句，并有助于提高可读性时，可将整个控制语句放在一行中。
说明：以减少相邻控制结构造成的代码不明确。
- 用括号明确表达式的运算顺序，即对较复杂的计算或条件判断，尽量多在适当处增加括号以避免歧义。
- 少用语义难懂的语句，如：iNum = iLen + iPos++ ; ”++” , ”--” 等操作最好不与其他语句合在一起写，以增加代码可读性，如果必须使用请加括号。
- 三元条件运算符” ? :”的条件如果是表达式，则条件表达式要用圆括号括起来。
- 在switch语句的最后一个case分支中要加上break语句。
- 用equals()，而不是”==”，来判断对象是否相等。
注意：当name为null时，”Bob”.equals(name)不会抛出异常，因此不建议使用name.equals(”Bob”)。
7. 不要悄无声息地吸收运行时异常,catch中要有相应的处理。
说明：如数组越界等，会为debug带来了困难，至少应打印出栈信息，报告异常。
8. 后台模块的调试打印语句，一定要设置开关。可采用命令行输入条件、配置文件设置条件等方式。
9. 用finally块释放资源。
说明：如I/O流、数据库连接等。
10. 避免过多的使用同步。
说明：只在确实有必要时使用同步。不要同步提供基础数据类型或数据结构的类。
11. 如果方法中有不需要同步的重要操作，不要同步整个方法。
说明：通常只有方法中的少量操作需要同步，在这种情况下，方法级的同步就过粗了。应用同步的块语句来替代方法级的同步。
12. 在读写实例变量时避免不必要的同步。
说明：对原子数据（对象引用、除long和double外的所有原始数据类型）的读或写是原子操作，不需要同步。但如果非原子变量与其他变量相关，则有必要同步。
12. 考虑用notify()取代notifyAll()。
说明：notify()的效率更高。当多个线程等待不止一个条件，或者多个线程要对一个信号量作出响应时，才使用notifyAll()。
13. 使用懒惰初始化。
说明：即在声明时并不创建对象，以免编译不需要的对象，从而提高程序效率。但要注意的是对于局部变量，尽量在声明局部变量的同时进行初始化。唯一不这么做的理由是变量的初始值依赖于某些先前发生的计算。
14. 避免创建不必要的对象。
说明：这一点对不太使用或生命周期短的对象尤其重要。创建和回收不必要的对象会浪费运行时间。
举例：
A a = new A();
if(1 == i) {
list.add(a);
}
应该改为
if(1 == i) {
A a = new A();
list.add(a);
}
15. 重新初始化和重用对象，避免创建新的对象。
说明：用存取方法，而不是构造器，来重新初始化对象。
要注意，选用的实现应无需创建对象来管理保存对象。可使用工厂实现封装对对象的保存和重用。
16. 对公共方法、接口的优化要慎重。
说明：对代码的优化不应影响到公共的方法和接口，要保证公共方法和接口的稳定，除非确定有必要对它们进行优化。
17. import时尽量引用实际的类名，不要用”*”号。可以使用Eclipse快捷键（默认为Ctrl+Shift+O）自动导入所需的类、除去多余的导入。
18. 尽量在合适的场合使用单例。
说明：使用单例可以减轻加载的负担，缩短加载的时间，提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面：
1) 控制资源的使用，通过线程同步来控制资源的并发访问；
2) 控制实例的产生，以达到节约资源的目的；
3) 控制数据共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。
19. 尽量避免随意使用静态变量。
说明：当某个对象被定义为static变量所引用，那么GC通常是不会回收这个对象所占有的内存。
举例：
public class A{
static B b = new B();
}
此时静态变量b的生命周期与A类同步，如果A类不会卸载，那么b对象会常驻内存，直到程序终止。
20. 尽量使用局部变量。
说明：调用方法时传递的参数以及在调用中创建的临时变量都保存在栈(Stack)中，速度较快。其他变量，如静态变量，实例变量等，都在堆(Heap)中创建，速度较慢。
成员变量只有对象不被引用时才会被销毁，生命周期要比局部变量长的多，
21. 尽量减少对变量的重复计算。
举例：
for(int i = 0; i < list.size(); i++)
应该改为
for(int i = 0, len = list.size(); i < len; i++)
并且在循环中应该避免使用复杂的表达式，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。
22. 单线程应尽量使用HashMap, ArrayList。
说明：HashTable,Vector等使用了同步机制，降低了性能。
23. 尽量合理的创建HashMap等容器。
说明：当要创建一个比较大的hashMap时，充分利用另一个构造函数
public HashMap(int initialCapacity, float loadFactor)
避 免HashMap多次进行了hash重构,扩容是一件很耗费性能的事，在默认中initialCapacity只有16，而loadFactor是0.75，需要多大的容量，最好能准确的估计所需要的最佳大小，同样的Hashtable、Vector也是一样的道理。
HashMap在处理大量数据的操作时效率是很高的，但是小数据量时可以考虑使用HashSet来代替HashMap。
大量使用容器类的实例时，最好在使用完后将实例置为null，加速垃圾回收速度。
24. 尽量使用移位来代替'a/b'的操作，尽量使用移位来代替'a*b'的操作。
说明："/"和"*"都是代价很高的操作，使用移位的操作将会更快和更有效。
25. 尽量使用StringBuilder和StringBuffer进行字符串连接。
尽量确定StringBuffer的容量,StringBuilder类不是线程安全的，但其在单线程中的性能比StringBuffer高。
说明：StringBuffer的构造器会创建一个默认大小(通常是16)的字符数组。在使用中，如果超出这个大小，就会重新分配内存，创建一个更大的数组，并将原先的数组复制过来，再丢弃旧的数组。在大多数情况下，可以在创建StringBuffer的时候指定大小，这样就避免了在容量不够的时候自动增长，以提高性能。
26. 尽量早释放无用对象的引用。
说明：大部分时候，方法局部引用变量所引用的对象会随着方法结束而变成垃圾，因此，大部分时候程序无需将局部、引用变量显式设为null。但如果方法内需要执行耗时、耗内存的操作，就有必要将对象赋值为null，可以尽早的释放对对象的引用。
27. 尽量避免使用二维数组。
说明：二维数据占用的内存空间比一维数组多得多，大概10倍以上。
28. 尽量避免使用split。
说明：除非是必须的，否则应该避免使用split，split由于支持正则表达式，所以效率比较低，如果是频繁的几十，几百万的调用将会耗费大量资源，如果确实需要频繁的调用split，可以考虑使用apache的StringUtils.split(string,char)，频繁split的可以缓存结果。
29. 尽量使用System.arraycopy()代替通过来循环复制数组。
30. 尽量缓存经常使用的对象。
31. 尽量不要使用finalize方法。
说明：实际上，将资源清理放在finalize方法中完成是非常不好的选择，由于GC的工作量很大，尤其是回收Young代内存时，大都会引起应用程序暂停，所以再选择使用finalize方法进行资源清理，会导致GC负担更大，程序运行效率更差。
32. 选择合适的字符集。
说明：String的以下两个方法会产生字符集的问题，如下：
new String(bytes)
getBytes()
正确的做法：
调用这两个方法时，会使用JVM默认字符集，因此不同的操作系统下会返回不同的结果，因此必须对在使用String以上两个方法的地方逐一修改，使用以下两个方法：
new String(bytes , NAME_OF_CHARSET)
getBytes( NAME_OF_CHARSET)
其中，NAME_OF_CHARSET表示字符集编码方式。实例：
// 根据默认编码获取字节数组
byte[] bytes=new byte[0];
try {
bytes = str.getBytes("GB18030");
} catch (UnsupportedEncodingException e) {
// TODO Auto-generated catch block
logger.error(e);
}
关于选用何种字符集？需要根据需求确定，比如需要解析的数据（MIB节点）只支持英文，可选用”ISO-8859-1”。
32. 注意数据库相关资源的释放。
错误的写法：
Connection conn = DBConnectionManager.getConnection(); // (1)
try{
String sql = "xxxx";
PreparedStatement pt = conn.prepareStatement(sql); // (2)
ResultSet rs = pt.executeQuery(sql); // (3)
while(rs.next()) {
xxxxx;
}
rs.close(); // (4)
pt.close(); // (5)
} catch(Exception e) {
logger.error(e);
} finally {
try {
conn.close();
} catch (Exception e) {
logger.error(e);
}
}
注意以上标记有数字的注释部分，在try子句内抛异常时有可能引起rs和pt/st没有关闭。因此建议把声明和初始化分开，把声明提到try子句外面去，在finally子句里面用:
DBConnectionManager.getInstance().free(conn,pt,rs)
来确保全部都能够关闭。（free方法在释放资源前有对null的校验，不用担心抛空指针）。
正确的书写方式如下：
Connection conn = DBConnectionManager.getConnection(); // (1)
PreparedStatement pt = null; // (2)
ResultSet rs = null; // (3)
try{
if(conn != null) {
String sql = "xxxx";
pt = conn.prepareStatement(sql); // (4)
rs = pt.executeQuery(sql); // (5)
while(rs.next()) {
xxxxx;
}
}
} catch(Exception e) {
logger.error(e);
} finally {
DBConnectionManager.getInstance().free(conn, pt, rs); // (6)
}
32. 避免用一个对象访问一个类的静态变量和方法，应该用类名替代。
33. 避免在一个语句中给多个变量赋相同的值。它很难读懂。例如：
举例：
fooBar.fChar = barFoo.lchar = ‘c’;
这种写法是不推荐的。
34. 慎用异常
当 创建一个异常时，需要收集一个栈跟踪(stack track)，这个栈跟踪用于描述异常是在何处创建的。构建这些栈跟踪时需要为运行时栈做一份快照，正是这一部分开销很大。当需要创建一个 Exception 时，JVM 不得不说：先别动，我想就您现在的样子存一份快照，所以暂时停止入栈和出栈操作。栈跟踪不只包含运行时栈中的一两个元素，而是包含这个栈中的每一个元素。
如 果您创建一个 Exception ，就得付出代价。好在捕获异常开销不大，因此可以使用 trycatch 将核心内容包起来。从技术上讲，您甚至可以随意地抛出异常，而不用花费很大的代价。招致性能损失的并不是 throw 操作——尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。真正要花代价的是创建异常。幸运的是，好的编程习惯已教会我们，不应该不管三七二十一就 抛出异常。异常是为异常的情况而设计的，
