软件开发的过程中应该避免哪些java功能，看看武汉北大青鸟中南软件学院给予的讲解吧！

1.Bytecode manipulation.

字节码操作，如果我看到你在Java EE应用程序里直接使用CGLIB或ASM，我可能会立即跑开。

糟糕的事情莫过于在编译期间没有任何可执行的代码。实际上，当产品在运行时，你根本不知道哪块代码在运行。所以，当你遇到麻烦时，会自然地把错误抛给运行时故障排除和调试，不过这样反而会更麻烦。

2.Reflection

Reflection即反射，在许多流行的库里面都有反射机制，比如Spring和Hibernate。通过对业务代码进行反思，我建议大家避免使用反射。

其次，反射调用优化是由JIT执行的，一些优化可能需要花费很长时间才能得到应用，而有些优化甚至都得不到应用，所以关于反射的性能优化有时会被数量化。但在一个典型的业务应用程序中——你可能不会真正意识到这些性能开销。

总之，开发者应该通过AOP合理地在业务层使用反射，除此以外，你更好离它远远的。

3.Classloaders

先，类加载器是一个复杂的野兽。你必须先了解它的层次结构、委托机制、类缓存等等。即使你认为自己已经掌握了，它可能还是不能正常工作。终将导致一个类加载器泄露问题。因此我只能建议你将这个任务留给应用服务器处理

4. Sockets

普通老式的java.net.Socket实在是太复杂，以至于很难弄正确。我觉得阻塞性是其根本性的缺陷。当你编写一个典型的带有Web前端的Java EE应用程序时，应用程序需要高并发度来支持大量的用户，而你现在不想发生的是不具有可扩展的线程池坐等阻塞套接字。

5.Weak/Soft references

现在，你应该更好的理解Java的内部方法。使用软引用来重写所有的缓存并不明智。我知道，当你手上拿着锤子的时候，就会到处寻找钉子。可对于锤子来说，缓存并不是个好钉子。为什么?基于软引用构建缓存可能是如何委托一些复杂因素到GC而不是通过自身实现的一个好例子。

6.ThreadLocals

这里有两个不相关的原因，当我在业务层代码里看到ThreadLocals时会颤抖。先，在ThreadLocals的帮助里，你可能会看到许多变量的使用都没有通过方法调用链来明确地向下传递。这在某些场合下是有用的，但当你一旦粗心，你会在代码里构建许多意料不到的依赖关系。

第二个不相关的原因与我日常的工作相关，在ThreadLocals里存储数据会引发内存泄露。起码我遇到的Permgen泄露有十分之一都是使用ThreadLocals造成的，在结合了类加载器和线程池后，“java.lang.OutOfMemoryError:Permgen space”异常可能就马上出现了。