开发者应该避免使用的6个Java功能.doc
文本预览下载声明
开发者应该避免使用的6个Java功能
广州传智播客作为华南地区Java与Android培训的领头羊，对Java与Android的研究都是走在互联网发展的潮流最前沿，把最新最好的技术教导给学生。
在课程体系外，还有很多细致的知识点分享给大家：
多年的Java开发经验告诉我，从长远角度来看，以下这些Java SE功能/API，开发者最好停止使用。
Reflection
Bytecode manipulation
ThreadLocals
Classloaders
Weak/Soft references
Sockets
1.Reflection
Reflection即反射，在许多流行的库里面都有反射机制，比如Spring和Hibernate。通过对业务代码进行反思，我建议大家避免使用反射。下面列出我反对使用的原因：
首先涉及到代码可读性/工具支持。打开IDE并且在Java代码里找到相互依赖关系。使用relection替换方法调用，并且试着重复该步骤。事情变的愈发不可收拾，正常情况下都应该封装好了再修改状态。下面来看看具体代码示例：
HYPERLINK /document/3145.html ?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33public class Secret {
private String secrecy;
public Secret(String secrecy) {
this.secrecy = secrecy;
}
public String getSecrecy() {
return null;
}
}
public class TestSecrecy {
public static void main(String[] args) throws Exception {
Secret s = new Secret(TOP SECRET);
Field f = Secret.class.getDeclaredField(secrecy);
f.setAccessible(true);
System.out.println(f.get(s));
}
} 通过查看以上代码可以得知，方法getDeclaredField()参数只有在运行时才可以被发现。而你也清楚，运行时产生的bug总比不执行脚本要更加棘手。
其次，反射调用优化是由JIT执行的，一些优化可能需要花费很长时间才能得到应用，而有些优化甚至都得不到应用，所以关于反射的性能优化有时会被数量化。但在一个典型的业务应用程序中——你可能不会真正意识到这些性能开销。
总之，开发者应该通过 HYPERLINK /wiki/Aspect-oriented_programming \t _blank AOP合理地在业务层使用反射，除此以外，你最好离它远远的。
2.Bytecode manipulation.
字节码操作，如果我看到你在Java EE应用程序里直接使用 HYPERLINK / \t _blank CGLIB或 HYPERLINK / \t _blank ASM，我可能会立即跑开。
最糟糕的事情莫过于在编译期间没有任何可执行的代码。实际上，当产品在运行时，你根本不知道哪块代码在运行。所以，当你遇到麻烦时，会自然地把错误抛给运行时故障排除和调试，不过这样反而会更麻烦。
3.ThreadLocals
这里有两个不相关的原因，当我在业务层代码里看到ThreadLocals时会颤抖。首先，在ThreadLocals的帮助里，你可能会看到许多变量的使用都没有通过方法调用链来明确地向下传递。这在某些场合下是有用的，但当你一旦粗心，你会在代码里构建许多意料不到的依赖关系。
第二个不相关的原因与我日常的工作相关，在ThreadLocals里存储数据会引发内存泄露。最起码我遇到的Permgen泄露有十分之一都是使用ThreadLocals造成的，在结合了类加载器和线程池后，“java.lang.OutOfMemoryError:Permgen space”异常可能就马上出现了。
4.Classloaders
首先，类加载器是一个复杂的野兽。你必须先了解它的层次结构、委托机制、类缓存等等。即使你认为自己已经掌握了，它可能还是不能正常工作。最终将导致一个类加载器泄露问题。因此我只能建议你将这个任务留给应用服务器处理
5.Weak/Soft references
现在，你应该更好的理解Java的内部方法。
显示全部