java六大原则

我花了无数小时来对不同的应用程序进行故障排除。 通过经验，我可以得出关于大多数开发人员应该远离的几个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

java六大原则