本文作者是一名拥有多年Java开发经验的程序员，他从经验中得出，并不是所有的Java SE功能/API都值得程序员去使用，比如本文列举的这6个，大家在使用前得慎重对待。以下是对原文的摘译。
多年的Java开发经验告诉我，从长远角度来看，以下这些Java SE功能/API，开发者最好停止使用。
- Reflection
- Bytecode manipulation
- ThreadLocals
- Classloaders
- Weak/Soft references
- Sockets
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
您还没有登录,请您登录后再发表评论
26 楼 zidafone 2013-11-07 12:13
而是把这些留给服务器（比如Tomcat）或成熟的框架/库（比如Netty），并不是要把这些特性完全踢出Java。
我也不同意第一项，但其他的还是基本同意。
通常的泛用业务开发不该需要直接和这些东东打交道，即便需要开发框架也应该做些封装才好，特别是开发队伍人多且水平参差不齐时...
同意。作者的意思是，这些技术在应用层面的开发不适宜使用，它们是平台、框架、服务器这些级别的开发应该用到的。
反射也有著作反对日常使用的，是effective java还是rod johnson的哪本书来着。它破坏的是java的强类型特性。
如果你做那些插拔式的插件开发，没有反射咋搞
反对日常使用，不是说就不要反射了呀
较高级别的抽象上和一些具体事务上，反射当然是一个利器呀
只是大部分日常编码，用反射就是牛刀杀鸡
25 楼 alvin198761 2013-11-06 09:01
而是把这些留给服务器（比如Tomcat）或成熟的框架/库（比如Netty），并不是要把这些特性完全踢出Java。
我也不同意第一项，但其他的还是基本同意。
通常的泛用业务开发不该需要直接和这些东东打交道，即便需要开发框架也应该做些封装才好，特别是开发队伍人多且水平参差不齐时...
同意。作者的意思是，这些技术在应用层面的开发不适宜使用，它们是平台、框架、服务器这些级别的开发应该用到的。
反射也有著作反对日常使用的，是effective java还是rod johnson的哪本书来着。它破坏的是java的强类型特性。
如果你做那些插拔式的插件开发，没有反射咋搞
24 楼 zidafone 2013-11-02 09:57
而是把这些留给服务器（比如Tomcat）或成熟的框架/库（比如Netty），并不是要把这些特性完全踢出Java。
我也不同意第一项，但其他的还是基本同意。
通常的泛用业务开发不该需要直接和这些东东打交道，即便需要开发框架也应该做些封装才好，特别是开发队伍人多且水平参差不齐时...
同意。作者的意思是，这些技术在应用层面的开发不适宜使用，它们是平台、框架、服务器这些级别的开发应该用到的。
反射也有著作反对日常使用的，是effective java还是rod johnson的哪本书来着。它破坏的是java的强类型特性。
23 楼 zoozooll 2013-10-28 09:19
22 楼 alvin198761 2013-10-27 11:39
21 楼 alvin198761 2013-10-27 11:37
再说一点，楼主的反射代码写的会出问题，应该放到 访问控制里面去，
照这种心态，大家不要用煤气，电磁炉，不要生火做饭，不要用微波炉，不能用绞肉机，......
不要生孩子，不要在公路上走，不要旅游，不要爬山，不要搞火箭什么的...
在中国，不要吃东西，不要喝东西,不要呼吸...
20 楼 yanqingluo 2013-10-26 21:36
这些是容器和框架需要用的技术。
19 楼 accp_huangxin 2013-10-26 19:56
18 楼 jianfeng 2013-10-25 09:49
17 楼 xucaishen 2013-10-24 10:47
16 楼 Shen.Yiyang 2013-10-23 19:36
15 楼 socao 2013-10-23 15:04
14 楼 badqiu 2013-10-23 12:39
13 楼 moyan_java 2013-10-23 12:00
12 楼 lection.yu 2013-10-23 11:20
11 楼 Tyrion 2013-10-23 11:19
建议标题改成“初级开发者应该避免使用的6个Java功能”
10 楼 503718696 2013-10-23 10:36
9 楼 yanglphf 2013-10-23 09:38
8 楼 clxy 2013-10-22 19:48
而是把这些留给服务器（比如Tomcat）或成熟的框架/库（比如Netty），并不是要把这些特性完全踢出Java。
我也不同意第一项，但其他的还是基本同意。
通常的泛用业务开发不该需要直接和这些东东打交道，即便需要开发框架也应该做些封装才好，特别是开发队伍人多且水平参差不齐时...
7 楼 fjjiaboming 2013-10-22 18:26