java代码优化的方法和准则_编写高质量代码:改善Java程序的151个建议(第1章:JAVA开发中通用的方法和准则___建议16~20)...

建议16：易变业务使用脚本语言编写

Java世界一直在遭受着异种语言的入侵，比如PHP，Ruby，Groovy、Javascript等，这些入侵者都有一个共同特征：全是同一类语言-----脚本语言，它们都是在运行期解释执行的。为什么Java这种强编译型语言会需要这些脚本语言呢？那是因为脚本语言的三大特征，如下所示：

灵活：脚本语言一般都是动态类型，可以不用声明变量类型而直接使用，可以再运行期改变类型。

便捷：脚本语言是一种解释性语言，不需要编译成二进制代码，也不需要像Java一样生成字节码。它的执行时依靠解释器解释的，因此在运行期间变更代码很容易，而且不用停止应用；

简单：只能说部分脚本语言简单，比如Groovy，对于程序员来说，没有多大的门槛。

脚本语言的这些特性是Java缺少的，引入脚本语言可以使Java更强大，于是Java6开始正式支持脚本语言。但是因为脚本语言比较多，Java的开发者也很难确定该支持哪种语言，于是JSCP(Java Community ProCess)很聪明的提出了JSR233规范，只要符合该规范的语言都可以在Java平台上运行(它对JavaScript是默认支持的)。

简单看看下面这个小例子：

functionformual(var1, var2){return var1 + var2 * factor;

}

这就是一个简单的脚本语言函数，可能你会很疑惑:factor(因子)这个变量是从那儿来的？它是从上下文来的，类似于一个运行的环境变量。该js保存在C:/model.js中，下一步需要调用JavaScript公式，代码如下：

1 importjava.io.FileNotFoundException;2 importjava.io.FileReader;3 importjava.util.Scanner;4

5 importjavax.script.Bindings;6 importjavax.script.Invocable;7 importjavax.script.ScriptContext;8 importjavax.script.ScriptEngine;9 importjavax.script.ScriptEngineManager;10 importjavax.script.ScriptException;11

12 public classClient16 {13 public static void main(String[] args) throwsFileNotFoundException,14 ScriptException, NoSuchMethodException {15 //获得一个JavaScript执行引擎

16 ScriptEngine engine = new ScriptEngineManager().getEngineByName("javascript");17 //建立上下文变量

18 Bindings bind =engine.createBindings();19 bind.put("factor", 1);20 //绑定上下文，作用于是当前引擎范围

21 engine.setBindings(bind, ScriptContext.ENGINE_SCOPE);22 Scanner input =newScanner(System.in);23

24 while(input.hasNextInt()){25 int first =input.nextInt();26 int second =input.nextInt();27 System.out.println("输入参数是："+first+","+second);28 //执行Js代码

29 engine.eval(new FileReader("C:/model.js"));30 //是否可调用方法

31 if (engine instanceofInvocable) {32 Invocable in =(Invocable) engine;33 //执行Js中的函数

34 Double result = (Double) in.invokeFunction("formula", first, second);35 System.out.println("运算结果是：" +result.intValue());36 }37 }38

39 }40 }

上段代码使用Scanner类接受键盘输入的两个数字，然后调用JavaScript脚本的formula函数计算其结果，注意，除非输入了一个非int数字，否则当前JVM会一直运行，这也是模拟生成系统的在线变更情况。运行结果如下：

输入参数是;1,2  运算结果是：3

此时，保持JVM的运行状态，我们修改一下formula函数，代码如下：

functionformual(var1, var2){

return var1 + var2 - factor;

}

其中,乘号变成了减号，计算公式发生了重大改变。回到JVM中继续输入，运行结果如下：

输入参数：1,2  运行结果是：2

修改Js代码，JVM没有重启，输入参数也没有任何改变，仅仅改变脚本函数即可产生不同的效果。这就是脚本语言对系统设计最有利的地方：可以随时发布而不用部署；这也是我们javaer最喜爱它的地方----即使进行变更，也能提供不间断的业务服务。

Java6不仅仅提供了代码级的脚本内置，还提供了jrunscript命令工具，它可以再批处理中发挥最大效能，而且不需要通过JVM解释脚本语言，可以直接通过该工具运行脚本。想想看。这是多么大的诱惑力呀！而且这个工具是可以跨操作系统的，脚本移植就更容易了。

建议17：慎用动态编译

动态编译一直是java的梦想，从Java6开始支持动态编译了，可以再运行期直接编译.java文件，执行.class，并且获得相关的输入输出，甚至还能监听相关的事件。不过，我们最期望的还是定一段代码，直接编译，然后运行，也就是空中编译执行(on-the-fly)，看如下代码：

1 importjava.io.IOException;2 importjava.lang.reflect.Method;3 importjava.net.URI;4 importjava.util.ArrayList;5 importjava.util.Arrays;6 importjava.util.List;7

8 importjavax.tools.JavaCompiler;9 importjavax.tools.JavaFileObject;10 importjavax.tools.SimpleJavaFileObject;11 importjavax.tools.StandardJavaFileManager;12 importjavax.tools.ToolProvider;13

14 public classClient17 {15 public static void main(String[] args) throwsException {16 //Java源代码

17 String sourceStr = "public class Hello { public String sayHello (String name) {return \"Hello,\"+name+\"!\";}}";18 //类名及文件名

19 String clsName = "Hello";20 //方法名

21 String methodName = "sayHello";22 //当前编译器

23 JavaCompiler cmp =ToolProvider.getSystemJavaCompiler();24 //Java标准文件管理器

25 StandardJavaFileManager fm = cmp.getStandardFileManager(null, null,26 null);27 //Java文件对象

28 JavaFileObject jfo = newStringJavaObject(clsName, sourceStr);29 //编译参数，类似于javac 中的options

30 List optionsList = new ArrayList();31 //编译文件的存放地方，注意：此处是为Eclipse工具特设的

32 optionsList.addAll(Arrays.asList("-d", "./bin"));33 //要编译的单元

34 List jfos =Arrays.asList(jfo);35 //设置编译环境

36 JavaCompiler.CompilationTask task = cmp.getTask(null, fm, null,37 optionsList, null, jfos);38 //编译成功

39 if(task.call()) {40 //生成对象

41 Object obj =Class.forName(clsName).newInstance();42 Class extends Object> cls =obj.getClass();43 //调用sayHello方法

44 Method m = cls.getMethod(methodName, String.class);45 String str = (String) m.invoke(obj, "Dynamic Compilation");46 System.out.println(str);47 }48

49 }50 }51

52 class StringJavaObject extendsSimpleJavaFileObject {53 //源代码

54 private String content = "";55

56 //遵循Java规范的类名及文件

57 publicStringJavaObject(String _javaFileName, String _content) {58 super(_createStringJavaObjectUri(_javaFileName), Kind.SOURCE);59 content =_content;60 }61

62 //产生一个URL资源路径

63 private staticURI _createStringJavaObjectUri(String name) {64 //注意，此处没有设置包名

65 return URI.create("String:///" + name +Kind.SOURCE.extension);66 }67

68 //文本文件代码

69 @Override70 public CharSequence getCharContent(booleanignoreEncodingErrors)71 throwsIOException {72 returncontent;73 }74 }

上面代码较多，可以作为一个动态编译的模板程序。只要是在本地静态编译能够实现的任务，比如编译参数，输入输出，错误监控等，动态编译都能实现。

Java的动态编译对源提供了多个渠道。比如，可以是字符串，文本文件，字节码文件，还有存放在数据库中的明文代码或者字节码。汇总一句话，只要符合Java规范的就可以在运行期动态加载，其实现方式就是实现JavaFileObject接口，重写getCharContent、openInputStream、openOutputStream，或者实现JDK已经提供的两个SimpleJavaFileObject、ForwardingJavaFileObject,具体代码可以参考上个例子。

动态编译虽然是很好的工具，让我们可以更加自如的控制编译过程，但是在我们目前所接触的项目中还是使用较少。原因很简单，静态编译已经能够帮我们处理大部分的工作，甚至是全部的工作，即使真的需要动态编译，也有很好的替代方案，比如Jruby、Groovy等无缝的脚本语言。另外，我们在使用动态编译时，需要注意以下几点：

在框架中谨慎使用：比如要在struts中使用动态编译，动态实现一个类，它若继承自ActionSupport就希望它成为一个Action。能做到，但是debug很困难；再比如在Spring中，写一个动态类，要让它注入到Spring容器中，这是需要花费老大功夫的。

不要在要求性能高的项目中使用：如果你在web界面上提供了一个功能，允许上传一个java文件然后运行，那就等于说:"我的机器没有密码，大家都可以看看"，这是非常典型的注入漏洞，只要上传一个恶意Java程序就可以让你所有的安全工作毁于一旦。

记录动态编译过程：建议记录源文件，目标文件，编译过程，执行过程等日志，不仅仅是为了诊断，还是为了安全和审计，对Java项目来说，空中编译和运行时很不让人放心的，留下这些依据可以很好地优化程序。

建议18：避免instanceof非预期结果

instanceof是一个简单的二元操作符，它是用来判断一个对象是否是一个类的实现，其操作类似于>=、==，非常简单，我们看段程序，代码如下:

1 importjava.util.Date;2

3 public classClient18 {4 public static voidmain(String[] args) {5 //String对象是否是Object的实例 true

6 boolean b1 = "String" instanceofObject;7 //String对象是否是String的实例 true

8 boolean b2 = new String() instanceofString;9 //Object对象是否是String的实例 false

10 boolean b3 = new Object() instanceofString;11 //拆箱类型是否是装箱类型的实例 编译不通过

12 boolean b4 = 'A' instanceofCharacter;13 //空对象是否是String的实例 false

14 boolean b5 = null instanceofString;15 //转换后的空对象是否是String的实例 false

16 boolean b6 = (String) null instanceofString;17 //Date是否是String的实例 编译不通过

18 boolean b7 = new Date() instanceofString;19 //在泛型类型中判断String对象是否是Date的实例 false

20 boolean b8 = new GenericClass().isDateInstance("");21

22 }23 }24

25 class GenericClass{26 //判断是否是Date类型

27 public booleanisDateInstance(T t) {28 return t instanceofDate;29 }30

31 }

就这么一段程序，instanceof的应用场景基本都出现了，同时问题也产生了：这段程序中哪些语句编译不通过，我们一个一个的解释说:

"String" instanceofObject：返回值是true，这很正常,"String"是一个字符串，字符串又继承了Object，那当然返回true了。

new String() instanceofString：返回值是true，没有任何问题，一个类的对象当然是它的实例了。

new Object() instanceofString：返回值为false，Object是父类，其对象当然不是String类的实例了。要注意的是，这句话其实完全可以编译通过，只要instanceof关键字的左右两个操作数有继承或实现关系，就可以编译通过。

'A' instanceofCharacter：这句话编译不通过，为什么呢？因为'A'是一个char类型，也就是一个基本类型，不是一个对象，instanceof只能用于对象的判断，不能用于基本类型的判断。

null instanceofString：返回值为false，这是instanceof特有的规则，若做操作数为null，结果就直接返回false，不再运算右操作数是什么类。这对我们的程序非常有利，在使用instanceof操作符时，不用关心被判断的类(也就是左操作数)是否为null，这与我们经常用到的equals、toString方法不同。

(String) null instanceofString：返回值为false，不要看这里有个强制类型转换就认为结果是true，不是的，null是一个万用类型，也就是说它可以没类型，即使做类型转换还是个null。

new Date() instanceofString：编译不通过，因为Date类和String没有继承或实现关系，所以在编译时就直接报错了，instanceof操作符的左右操作数必须有继承或实现关系，否则编译会失败。

new GenericClass().isDateInstance("")：编译不通过，非也，编译通过了，返回值为false，T是个String类型，于Date之间没有继承或实现关系，为什么"t instanceof Date"会编译通过呢？那是因为Java的泛型是为编码服务的，在编译成字节码时，T已经是Object类型了传递的实参是String类型，也就是说T的表面类型是Object，实际类型是String，那么"t instanceof Date"等价于"Object instanceof Date"了，所以返回false就很正常了。

建议19：断言绝对不是鸡肋

在防御式编程中经常会用断言(Assertion)对参数和环境做出判断，避免程序因不当的判断或输入错误而产生逻辑异常，断言在很多语言中都存在，C、C++、Python都有不同的断言表现形式.在Java中断言使用的是assert关键字，其基本用法如下：

assert

assert :

在布尔表达式为假时，跑出AssertionError错误，并附带了错误信息。assert的语法比较简单，有以下两个特性：

(1)、assert默认是不启用的

我们知道断言是为调试程序服务的，目的是为了能够迅速、方便地检查到程序异常，但Java在默认条件下是不启用的，要启用就要在编译、运行时加上相关的关键字，这就不多说，有需要的话可以参考一下Java规范。

(2)、assert跑出的异常AssertionError是继承自Error的

断言失败后，JVM会抛出一个AssertionError的错误，它继承自Error，注意，这是一个错误，不可恢复，也就是表明这是一个严重问题，开发者必须予以关注并解决之。

assert虽然是做断言的，但不能将其等价于if...else...这样的条件判断，它在以下两种情况下不可使用：

(1)、在对外的公开方法中

我们知道防御式编程最核心的一点就是：所有的外部因素(输入参数、环境变量、上下文)都是"邪恶"的，都存在着企图摧毁程序的罪恶本源，为了抵制它，我们要在程序处处检验。满地设卡，不满足条件，就不执行后续程序，以保护后续程序的正确性，处处设卡没问题，但就是不能用断言做输入校验，特别是公开方法。我们开看一个例子：

1 public classClient19 {2 public static voidmain(String[] args) {3 System.out.println(StringUtils.encode(null));;4 }5 }6

7 classStringUtils{8 public staticString encode(String str){9 assert str != null : "加密的字符串为null";10 /*加密处理*/

11 returnstr;12

13 }14 }

encode方法对输入参数做了不为空的假设，如果为空，则抛出AssertionError错误，但这段程序存在一个严重的问题，encode是一个public方法，这标志着它时对外公开的，任何一个类只要能传递一个String类型的参数(遵守契约)就可以调用，但是Client19类按照规定和契约调用encode方法，却获得了一个AssertionError错误信息，是谁破坏了契约协议？---是encode方法自己。

(2)、在执行逻辑代码的情况下

assert的支持是可选的，在开发时可以让他运行，但在生产环境中系统则不需要其运行了(以便提高性能)，因此在assert的布尔表达式中不能执行逻辑代码，否则会因为环境的不同而产生不同的逻辑，例如：

public voiddoSomething(List list, Object element) {assert list.remove(element) : "删除元素" + element + "失败";/*业务处理*/}

这段代码在assert启用的环境下没有任何问题，但是一但投入到生成环境，就不会启用断言了，而这个方法就彻底完蛋了，list的删除动作永远不会执行，所以就永远不会报错或异常了，因为根本就没有执行嘛！

以上两种情况下不能使用断言assert，那在什么情况下能够使用assert呢？一句话：按照正常的执行逻辑不可能到达的代码区域可以防止assert。具体分为三种情况：

在私有方法中放置assert作为输入参数的校验：在私有方法中可以放置assert校验输入参数，因为私有方法的使用者是作者自己，私有的方法的调用者和被调用者是一种契约关系，或者说没有契约关系，期间的约束是靠作者自己控制的，因此加上assert可以更好地预防自己犯错，或者无意的程序犯错。

流程控制中不可能到达的区域：这类似于Junit的fail方法，其标志性的意义就是，程序执行到这里就是错误的，例如：

public voiddoSomething() {int i = 7;while (i > 7) {/*业务处理*/}assert false : "到达这里就表示错误";

}

3.建立程序探针：我们可能会在一段程序中定义两个变量，分别代两个不同的业务含义，但是两者有固定的关系，例如:var1=var2 * 2，那我们就可以在程序中到处设"桩"了，断言这两者的关系，如果不满足即表明程序已经出现了异常，业务也就没有必要运行下去了。

建议20：不要只替换一个类

我们经常在系统中定义一个常量接口(或常量类)，以囊括系统中所涉及的常量，从而简化代码，方便开发，在很多的开源项目中已经采用了类似的方法，比如在struts2中，org.apache.struts2.StrutsConstants就是一个常量类，它定义Struts框架中与配置有关的常量，而org.apache.struts2.StrutsConstants则是一个常量接口，其中定义了OGNL访问的关键字。

关于常量接口(类)我们开看一个例子，首先定义一个常量类：

public classConstant {//定义人类寿命极限

public static final int MAX_AGE=150;

}

这是一个非常简单的常量类，定义了人类的最大年龄，我们引用这个常量，代码如下：

public classClient{public static voidmain(String[] args) {

System.out.println("人类的寿命极限是："+Constant.MAX_AGE);

}

}

运行结果easy，故省略。目前的代码是写在"智能型"IDE工具中完成的，下面暂时回溯到原始时代，也就是回归到用记事本编写代码的年代，然后看看会发生什么事情(为什么要如此，下面会给出答案)

修改常量Constant类，人类的寿命极限增加了，最大活到180,代码如下：

public classConstant {

//定义人类寿命极限

public static final int MAX_AGE=180;

}

然后重新编译，javac Constant，编译完成后执行：java Client，大家猜猜输出的年龄是多少？

输出的结果是:"人类的寿命极限是150"，竟然没有改成180，太奇怪了，这是为何？

原因是：对于final修饰的基本类型和String类型，编译器会认为它是稳定态的(Immutable Status)所以在编译时就直接把值编译到字节码中了，避免了在运行期引用(Run-time Reference)，以提高代码的执行效率。对于我们的例子来说，Client类在编译时字节码中就写上了"150",这个常量，而不是一个地址引用，因此无论你后续怎么修改常量类，只要不重新编译Client类，输出还是照旧。

对于final修饰的类(即非基本类型)，编译器会认为它不是稳定态的(Mutable Status)，编译时建立的则是引用关系(该类型也叫作Soft Final)。如果Client类引入的常量是一个类或实例，及时不重新编译也会输出最新值。

千万不可小看了这点知识，细坑也能绊倒大象，比如在一个web项目中，开发人员修改了一个final类型的值(基本类型)考虑到重新发布的风险较大，或者是审批流程过于繁琐，反正是为了偷懒，于是直接采用替换class类文件的方式发布，替换完毕后应用服务器自动重启，然后简单测试一下，一切Ok，可运行几天后发现业务数据对不上，有的类(引用关系的类)使用了旧值，有的类(继承关系的类)使用的是新值，而且毫无头绪，让人一筹莫展，其实问题的根源就在于此。

还有个小问题没有说明，我们的例子为什么不在IDE工具(比如Eclipse)中运行呢？那是因为在IDE中设置了自动编译不能重现此问题，若修改了Constant类，IDE工具会自动编译所有的引用类,"智能"化屏蔽了该问题，但潜在的风险其实仍然存在，我记得Eclipse应该有个设置自动编译的入口，有兴趣大家可以自己尝试一下。

注意：发布应用系统时禁止使用类文件替换方式，整体WAR包发布才是万全之策。但我觉得应特殊情况特殊对待，并不可以偏概全，大家以为呢？