java六大原则_六大Java功能

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 。

参考： Plumbr Blog博客上的六种Java功能使我们远离 JCG合作伙伴 Nikita Salnikov Tarnovski 。