class="topic_img" alt=""/>
英文原文：Six Java features to stay away from
本文作者是一名拥有多年 Java 开发经验的程序员，他从经验中得出，并不是所有的 Java SE 功能/API 都值得程序员去使用，比如本文列举的这 6 个，大家在使用前得慎重对待。以下是对原文的摘译。
多年的 Java 开发经验告诉我，从长远角度来看，以下这些 Java SE 功能/API，开发者最好停止使用。
1. Reflection
Reflection 即反射，在许多流行的库里面都有反射机制，比如 Spring 和 Hibernate。通过对业务代码进行反思，我建议大家避免使用反射。下面列出我反对使用的原因：
首先涉及到代码可读性/工具支持。打开 IDE 并且在 Java 代码里找到相互依赖关系。使用 relection 替换方法调用，并且试着重复该步骤。事情变的愈发不可收拾，正常情况下都应该封装好了再修改状态。下面来看看具体代码示例：
public 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 执行的，一些优化可能需要花费很长时间才能得到应用，而有些优化甚至都得不到应用，所以关于反射的性能优化有时会被数量化。但在一个典型的业务应用程序中——你可能不会真正意识到这些性能开销。
总之，开发者应该通过 AOP 合理地在业务层使用反射，除此以外，你最好离它远远的。
2. Bytecode manipulation.
字节码操作，如果我看到你在 Java EE 应用程序里直接使用 CGLIB 或 ASM，我可能会立即跑开。
最糟糕的事情莫过于在编译期间没有任何可执行的代码。实际上，当产品在运行时，你根本不知道哪块代码在运行。所以，当你遇到麻烦时，会自然地把错误抛给运行时故障排除和调试，不过这样反而会更麻烦。
3. ThreadLocals
这里有两个不相关的原因，当我在业务层代码里看到 ThreadLocals 时会颤抖。首先，在 ThreadLocals 的帮助里，你可能会看到许多变量的使用都没有通过方法调用链来明确地向下传递。这在某些场合下是有用的，但当你一旦粗心，你会在代码里构建许多意料不到的依赖关系。
第二个不相关的原因与我日常的工作相关，在 ThreadLocals 里存储数据会引发内存泄露。最起码我遇到的 Permgen 泄露有十分之一都是使用 ThreadLocals 造成的，在结合了类加载器和线程池后，“java.lang.OutOfMemoryError:Permgen space”异常可能就马上出现了。
4. Classloaders
首先，类加载器是一个复杂的野兽。你必须先了解它的层次结构、委托机制、类缓存等等。即使你认为自己已经掌握了，它可能还是不能正常工作。最终将导致一个类加载器泄露问题。因此我只能建议你将这个任务留给应用服务器处理
5. Weak/Soft references
现在，你应该更好的理解 Java 的内部方法。使用软引用来重写所有的缓存并不明智。我知道，当你手上拿着锤子的时候，就会到处寻找钉子。可对于锤子来说，缓存并不是个好钉子。为什么？基于软引用构建缓存可能是如何委托一些复杂因素到 GC 而不是通过自身实现的一个好例子。
下面举个缓存的例子，你使用软引用来创建数据，当内存被耗尽时，GC 进入并且进行清理。但是，缓存中被删除的对象并未得到你的控制，而且很有可能在下一次的 cache-miss 中重新创建。如果内存仍然不足，你可以触发 GC 进行再次清理。你可能已经看出了整个运行过程的恶性循环，整个应用程序就变成了 CPU 与 GC 不断运行的状态了
6. Sockets
普通老式的 java.net.Socket 实在是太复杂，以至于很难弄正确。我觉得阻塞性是其根本性的缺陷。当你编写一个典型的带有 Web 前端的 Java EE 应用程序时，应用程序需要高并发度来支持大量的用户，而你现在最不想发生的是不具有可扩展的线程池坐等阻塞套接字。
目前有许多精彩可用的第三方库，使用它们可以更好的完成任务，比如 Netty，开发者不妨尝试下。
via:Plumbr
相关文章
