每个Java开发人员应拥有的持久断点

当开发人员使用Java进行工作时，即使您尝试调试其他内容，也总是会遇到一些失败的情况。这是应该在每个IDE中启用的持久断点的列表。（恕我直言）

是的，从理论上讲，您应该能够从良好的日志记录实现中获得此信息。但是这些问题通常是由于无法控制的更改而在其他人的库中深层隐患……或仅隐藏在大量当前正在执行的线程中。如今的Java在调试模式下运行没有太多开销，通常，如果没有附加调试器，我永远不会运行我正在处理的任何事情，因为HotSwap极大地提高了生产率。

我很想知道其他人必须有断点。它们应该是您想立即知道的，在应用程序的正常运行中永远都不会出现的故障。

死锁检测

VM在识别底层Java合约中的死锁方面越来越好，调试器应该可以选择打破死锁。您应确保默认情况下已将其打开。

在java.lang.ExceptionInInitializer上

进行跟踪可能会很痛苦，因为在更深的一层它可能会变成ClassNotFoundException，并且通常，如果下降了多个级别，则没有明显的原因可以使间接引用类无法加载。

通常是由于人们使用引发RuntimeExceptions的方法/构造函数初始化公共/最终/静态变量。如果不确定使用带有正确错误处理的static {}块，请不要在其中执行依赖于当前jar文件外部内容的操作。

在java.lang.NoClassDefFoundError上

在OSGi中工作时总是很流行，通常您忘记了一个依赖的jar文件，并且看到这种类型的故障。有趣的是，有时您只会在特定类的第一次抛出此异常时才找到原因。因此，如果您有断点，则可以更快地进行跟踪。

我发现有时候在一些反射代码后面没有碰到断点。在那种情况下，我经常在此类的构造函数中有断点以确保。

在java.lang.NoSuchMethodError上

如果您在本地未正确构建，或者使用的是错配版本的库，那么您当然通常会看到此信息。您总是想知道这一点。

在java.lang.LinkageError上

通常，只有在情况确实变糟时才出现这种情况，例如，当您挂起同一个类的两个版本，即使它们来自同一个jar文件时。（必须爱多级装载机）值得庆幸的是，这些装载机不会经常出现，通常会在我已经非常头痛的时候进行。

关于java.lang.OutOfMemoryError / java.lang.StackOverflowException

如果您很幸运，VM会为此中断。但是不幸的是，在本机代码中会发生很多时间，您只需要处理这些后果。

为后者获取完整的堆栈有点麻烦；但并非不可能。有关获取完整堆栈跟踪的信息，请参见此较早的文章。

在java.lang.AssertionError上

数量惊人的人使用断言，然后在调试或运行测试时抱怨异常时感到不高兴。（您正在使用-ea执行此操作，对吗？）

缺点是您想在调试某些测试框架时将其关闭，我正在查看您的JUnit，因为当您只想运行所有测试时碰到断点并没有完全帮助。

最后，我会不时地遍历以下代码，这将导致一个异常，仅用于测试是否启用了断言。

boolean assertionsEnabled = false;try{ assert false; }catch (AssertionException ae){ assertionsEnabled = true }

更新：一位乐于助人的同事指出，我应该就应替换此代码提供一些替代建议。第一种选择是调用Class.desiredAssertionStatus，但是如果您要完全确定，可以使用以下代码，该代码使用赋值来捕获断言状态而不会引发异常。

boolean assertionsEnabled = false;assert isAssertionsEnabled = true;

参考： Gerard Davison博客博客中，每个Java开发人员都应从我们的JCG合作伙伴 Gerard Davison获得持久性断点。

翻译自: https://www.javacodegeeks.com/2013/05/persistent-breakpoints-every-java-developer-should-have.html