我花了无数小时来对不同的应用程序进行故障排除。 通过经验,我可以得出关于大多数开发人员应该远离的几个Java SE功能/ API的结论。 当我提到大多数开发人员时,我会想到常规的Java EE开发人员,而不是库设计人员/基础结构工程师。
全面披露:老实说,我确实认为,大多数团队最好远离以下功能。 但是像往常一样,也有例外。 如果您有强大的团队并且完全了解自己在做什么,请继续。 但是,在大多数情况下,如果您开始在军械库中包括以下工具,从长远来看,您会后悔的:
- 反射
- 字节码操作
- ThreadLocals
- 类加载器
- 弱/软引用
- 插座
但是足够的介绍,让我仔细阅读警告标志列表,并附上潜在问题的解释:
反思 。 在诸如Spring和Hibernate之类的流行库中,反射有其应有的地位。 但是对业务代码进行内省是一件很糟糕的事情,其原因有很多,我几乎总是建议避免使用它:
首先是代码可读性/工具支持。 打开您喜欢的IDE,并在Java代码中找到相互依赖的关系。 很简单,不是吗? 现在,将方法调用替换为反射并尝试重复该过程。 当您开始修改通常应该封装的状态时,事情变得更加失控。 如果需要一个示例,请看以下代码:
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()参数中输入错误。 您可能还记得,发现运行时错误比被构建脚本拒绝要复杂得多。
最后,会有开销。 JIT对反射调用进行了不同的优化。 有些优化需要更长的时间才能应用,有些甚至无法应用。 因此,有时对反射的性能损失可能是几个数量级。 但是,在典型的业务应用程序上,您不会真正注意到开销,因此,这绝对可以减少麻烦。
总而言之,我可以指出,业务代码中唯一合理的(间接)反射用法是通过AOP 。 除此之外,您最好远离反射。
字节码操作 。 如果我看到您直接使用CGLIB或ASM您的Java EE应用程序代码,我感觉我立即想逃脱。 考虑我在反射块中阐述的原因,将影响倍增五倍,您可能会开始感到痛苦。
更糟糕的是,您在编译期间看不到可执行代码。 本质上,您不知道生产中实际上正在运行什么代码。 因此,当遇到麻烦时,您将不得不进行运行时故障排除和调试-如果您与我一致,这将花费更多的时间。
ThreadLocals 。 为什么在业务代码中看到ThreadLocals让我感到颤抖,有两个不相关的原因。 首先,在ThreadLocals的帮助下,您可能会开始感到使用变量的诱惑,而无需将它们显式传递给方法调用链。 在某些情况下可能有用。 但是当您不小心的时候,我可以保证您最终会在代码内创建许多意外的依赖项。
第二个原因与我的日常工作有关。 将数据存储在ThreadLocals中可以建立一条通往内存泄漏的通道。 我所面对的10个Permgen泄漏中至少有1个是由广泛的ThreadLocal使用引起的。 与类加载器和线程池结合使用 ,很好的旧“ java.lang.OutOfMemoryError:Permgen空间”指日可待。
类加载器 。 首先,类加载器是一个复杂的野兽。 您必须首先了解它们,层次结构,委派机制,类缓存等。即使您认为已理解它们,第一次(十次)尝试仍将无法正常进行。 至少您最终会导致类加载器泄漏。 因此,我只能建议将此任务留给应用程序服务器。
软参考和软参考 。 刚刚了解了它们是什么以及它们如何工作? 好。 现在,您对Java内部的了解会更好一些。 有一个用软引用重写所有缓存的好主意吗? 不好。 我确实知道,配备锤子会使您四处寻找钉子。
为什么我觉得对于这种锤子而言,缓存不是一个好主意,您可能会想知道。 毕竟,在软引用上构建缓存可能是一个很好的示例,说明了如何将某些复杂性委托给GC而不是自己实现。
让我们以任意缓存为例。 您可以使用值的软引用来构建它,以便在内存用尽时可以进入GC并开始清洁。 但是,现在您无法控制从缓存中删除了哪些对象,并且很有可能在下次缓存未命中时重新创建它们。 如果内存仍然不足,则触发GC再次清理它们。 我想您会看到恶性循环的形成,并且您的应用程序在Full GC不断运行的情况下成为CPU约束。
插座 。 普通的java.net.Socket太棘手,无法正确使用。 我确实认为它由于具有阻塞性而从根本上存在缺陷。 当使用基于Web的前端编写典型的Java EE应用程序时,您需要高度的并发性来支持众多用户。 您现在不希望发生的事情是让您的扩展池不那么可扩展,等待阻塞的套接字。
不过,还有许多出色的第三方库可用于手头的任务,因此,与其尝试自己解决问题,不如去抢购Netty 。
翻译自: https://www.javacodegeeks.com/2013/09/six-java-features-to-stay-away-from.html