远离java 6个功能

1.Reflection 反射

Spring和Hibernate等流行的库，用到反射。《但是业务代码坏在很多原因》

建议措施:

首先是代码可读性/工具支持。打开你最喜欢的IDE和在Java代码中找到相互依赖关系。很容易,不是吗?现在,将方法调用替换为反射并试图重复这个过程。事情更加失控,当你开始修改的状态通常应该封装。如果你需要一个例子,看看下面的代码:

public class Secret {
    
    @SuppressWarnings("unused")
    private String secrety;

    public Secret(String secrety) {
        super();
        this.secrety = secrety;
    }

    public String getSecrety() {
        return null;
    }
}
public class TestSecrecy {
    public static void main(String[] args) throws Exception {
        Secret s = new Secret("TOP SECRET");
        Field field = Secret.class.getDeclaredField("secrety");
        
        //设置可以访问private成员
        field.setAccessible(true);
        System.out.println(field.get(s));
    }
}

getDeclaredField()参数是在运行时才发现 ，错过编译时的安全性（检查）；发现运行错误是很多时候比你的构建脚本错误更加棘手，困难

最后,反射将会有开销，它的调用是由JIT优化。一些优化需要更长的时间来申请,有的甚至不能应用。所以反射的性能损失,有时是数量级。

但在一个典型的业务应用程序,你会没有注意到开销,这绝对是一个只是两害相权取其轻。

总而言之,我可以理解,唯一合理的(间接)反映在你业务代码是通过使用AOP。除此之外,你最好远离反射。

 

2.字节码操作

如果使用CGLIB或ASM直接您的Java EE应用程序代码中，会使事情变得很糟糕

你没有可执行代码在编译时的一个地方。从本质上讲,你不知道什么代码实际上是运行在您的生产。所以当面对麻烦你扔进运行时故障诊断和调试。

3.Threadlocal

有两个不相关的原因看到threadlocal在业务代码让我很不友好。

首先,threadlocal的帮助下,你可以开始感到诱惑没有显式地使用变量传递下来通过方法调用链。这可能是有用的在某些场合。

但是当你不小心的时候,我可以保证你将会创建很多意想不到的依赖在你的代码。

第二个原因是我日常工作相关。在threadlocal存储数据构建高速highway内存泄漏。

至少有一个出了10 PermGen的渗漏是由大量的ThreadLocal的使用造成的。

在与类加载器和线程池相结合，“java.lang.OutOfMemoryError：Permgen space”是指日可待。

4.类加载器（Classloaders）

首先，类加载器是一个复杂的。你必须先了解他们，层次结构，代表团力学，类缓存，等等。而且，即使你认为你已经得到它，第一个（10？），企图将仍然无法正常工作。在最低限度，你最终将建立一个类加载器泄漏。所以，我只能建议保留此任务的应用程序服务器。

5.弱引用和软引用（Weak and Soft References）

 可以查看这里：http://www.cnblogs.com/pjcdarker/p/4820512.html

在软引用构建缓存可能是如何委派一些复杂性的GC，而不是自己实现它自己一个很好的例子。

以一个任意的缓存为例。你建立它使用软引用的值,因此当内存耗尽GC可以介入并开始清理。但是现在你没有控制哪些对象被从缓存中删除,而且更有可能将它们重新创建的下一个高速缓存（因为不知道那些对象可以删除 ，缺失的对象可能会重新创建）。如果内存仍然是稀缺引发GC再次清理。恶性循环形成和应用程序成为CPU绑定的完整GC不断运行

6.套接字（Sockets）

java.net.Socket有点扯淡了。由于阻塞性质。

当编写一个典型的Java EE应用程序使用一个基于web的前端需要高度的并发支持大量用户。

你现在不希望发生的事情是线程池坐在那里等待阻塞套接字。

 注：不太理解，还得努力学习；翻译也太烂了