你应该远离的6个Java特性

图片 1

我曾花费了无数个小时为各种不同的应用排错。根据过往的经验我可以得出这样一个结论,那就是对于大多数开发者来说,你应该远离几个Java
SE特性或是APIs。这里所说的大多数开发者指的是一般的Java
EE开发者而不是库设计者或是基础设施开发者。

本文作者是一名拥有多年Java开发经验的程序员,他从经验中得出,并不是所有的Java
SE功能/API都值得程序员去使用,比如本文列举的这6个,大家在使用前得慎重对待。以下是对原文的摘译。

坦白地说,从长远来看,大多数团队都应该远离如下的Java特性。不过凡事总有例外的情况。如果你有一个强大的团队,总是能够清楚地意识到自己在做什么,那就按照你的想法去做就行。但对于大多数情况来说,如果你在项目的开发中使用了下面这几个Java特性,那么从长远来看你是会后悔的。

多年的Java开发经验告诉我,从长远角度来看,以下这些Java
SE功能/API,开发者最好停止使用。 

这些应该远离的Java特性有:

  • Reflection
  • Bytecode manipulation 
  • ThreadLocals
  • Classloaders
  • Weak/Soft references
  • Sockets 
  • 反射
  • 字节码操纵
  • ThreadLocal
  • 类加载器
  • 弱引用与软引用
  • Sockets

1.Reflection

下面对这些特性进行逐个分析,看看为什么普通的Java开发者应该远离他们:

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

反射

在流行的库如Spring和Hibernate中,反射自然有其用武之地。不过内省业务代码在很多时候都不是一件好事,原因有很多,一般情况下我总是建议大家不要使用反射。

首先是代码可读性与工具支持。打开熟悉的IDE,寻找你的Java代码的内部依赖,很容易吧。现在,使用反射来替换掉你的代码然后再试一下,结果如何呢?如果通过反射来修改已经封装好的对象状态,那么结果将会变得更加不可控。请看看如下示例代码:

图片 1

如果这样做就无法得到编译期的安全保证。就像上面这个示例一样,你会发现如果getDeclaredField()方法调用的参数输错了,那么只有在运行期才能发现。要知道的是,寻找运行期Bug的难度要远远超过编译期的Bug。

最后还要谈谈代价问题。JIT对反射的优化程度是不同的,有些优化时间会更长一些,而有些甚至是无法应用优化。因此,有时反射的性能损失可以达到几个数量级的差别。不过在典型的业务应用中,你可能不会注意到这个代价。

总结一下,我觉得在业务代码中唯一合理(直接)使用反射的场景是通过AOP。除此之外,你最好远离反射这一特性。

首先涉及到代码可读性/工具支持。打开IDE并且在Java代码里找到相互依赖关系。使用relection替换方法调用,并且试着重复该步骤。事情变的愈发不可收拾,正常情况下都应该封装好了再修改状态。下面来看看具体代码示例:

字节码操纵

如果在Java
EE应用代码中直接使用了CGLIB或是ASM库,那么我建议你好好审视一下。就像方才我提到的反射带来的消极影响,使用字节码操纵所带来的痛苦可能是反射的好几倍之多。

更糟糕的是在编译期你根本就看不到可执行的代码。从本质上来说,你不知道产品中实际运行的是什么代码。因此在面对运行期的问题以及调试时,你要花费更多的时间。

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));
    }
}

ThreadLocal

看到业务代码中如果出现ThreadLocal会让我感到颤抖,原因有二。首先,借助于ThreadLocal,你可以不必显式通过方法调用就可以传递变量,而且会对这种做法上瘾。在某些情况下这么做可能是合理的,不过如果不小心,那么我可以保证最后代码中会出现大量意想不到的依赖。

第二个原因与我每天的工作有关。将数据存储在ThreadLocal中很容易造成内存泄漏,至少我所看到的十个永久代泄漏中就有一个是由过量使用ThreadLocal导致的。连同类加载器及线程池的使用,“java.lang.OutOfMemoryError:Permgen
space”就在不远处等着你呢。

通过查看以上代码可以得知,方法getDeclaredField()参数只有在运行时才可以被发现。而你也清楚,运行时产生的bug总比不执行脚本要更加棘手。

类加载器

首先,类加载器是个很复杂的东西。你必须首先理解他们,包括层次关系、委托机制以及类缓存等等。即便你觉得自己已经精通了类加载器,一开始使用时还是会出现各种各样的问题,很可能会导致类加载器泄漏问题。因此,我建议大家还是将类加载器留给应用服务器使用吧。

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

弱引用与软引用

关于弱引用与软引用,你是不是只知道他们是什么以及简单的使用方式而已?现在的你对Java内核有了更好的理解,那会不会使用软引用重写所有的缓存呢?这么做可不太好,可不能手里有锤子就到处找鼓敲吧。

你可能很想知道我为什么说缓存不太适用使用软引用吧。毕竟,使用软引用来构建缓存可以很好地说明将某些复杂性委托给GC来完成而不是自己去实现这一准则。

下面来举个例子吧。你使用软引用构建了一个缓存,这样当内存行将耗尽时,GC会介入并开始清理。但现在你根本就无法控制哪些对象会从缓存中删除,很有可能在下一次缓存中不再有这个对象时重新创建一次。如果内存还是很紧张,又触发GC执行了一次清理,那么很有可能会出现一个死循环,应用会占用大量CPU时间,Full
GC也会不断执行。

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

Sockets

java.net.Socket简直太难使用了。我认为它的缺陷归根结底源自其阻塞的本质。在编写具有Web前端的典型的Java
EE应用时,你需要高度的并发性来支持大量的用户访问。这时你最不想发生的事情就是让可伸缩性不那么好的线程池呆在那儿,等待着阻塞的Sockets。

现在已经出现了非常棒的第三方库来解决这些问题,别自己写了,尝试一下Netty吧。

Java出现至今经历了多次版本更迭,每次也都会有诸多新特性的加入。在日常的Java开发中,你认为存在哪些Java特性是很容易导致问题的呢?作者提到不建议在普通的应用开发中使用反射,不过对于一些框架或库的开发,离开反射实际上是无法实现的,例如Spring、Struts2等框架,那么在一般的Java项目开发中,你觉得哪些地方有使用反射的必要呢?换句话说,如果不使用反射就实现不了功能或是需求。文中作者也不建议使用字节码操纵,实际上一些框架在实现某些功能时是必须要使用的,比如说Spring在实现AOP时就使用了Java的动态代理与CGLib库两种方式来达成的。那么对于一般的Java项目来说,哪些地方需要用到字节码操纵呢?欢迎各位读者畅所欲言,一起讨论这些有趣的话题。

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,开发者不妨尝试下。

 

 

You can leave a response, or trackback from your own site.

Leave a Reply

网站地图xml地图