没有StackTrace的Java中的NullPointerException

我的Java代码实例捕获了NullPointerException，但是当我尝试登录StackTrace（基本上最终调用Throwable.printStackTrace()）时，我得到的是：

java.lang.NullPointerException

还有其他人遇到吗？我尝试谷歌搜索“ java空指针空堆栈跟踪”，但没有遇到这样的事情。

您可能正在使用HotSpot JVM（最初由Sun Microsystems，后来由Oracle收购，又是OpenJDK的一部分），它执行了很多优化。要获取堆栈跟踪，需要将选项传递-XX:-OmitStackTraceInFastThrow给JVM。

优化是，当第一次发生异常（通常为NullPointerException）时，将打印完整的堆栈跟踪，并且JVM会记住堆栈跟踪（或者可能只是代码的位置）。当该异常经常发生时，将不再打印堆栈跟踪，这既可以实现更好的性能，又不会使相同的堆栈跟踪充满日志。

要查看如何在HotSpot JVM中实现此功能，请获取它的副本并搜索global变量OmitStackTraceInFastThrow。上一次（在2019年）查看该代码时，该文件位于graphKit.cpp文件中。

正如您在评论中提到的那样，您正在使用log4j。我（无意间）发现了我写过的地方

LOG.error(exc);

而不是典型的

LOG.error("Some informative message", e);

通过懒惰或者也许只是不考虑它。不幸的是，它的行为不符合您的预期。logger API实际上将Object作为第一个参数而不是字符串-然后在该参数上调用toString（）。因此，它没有打印出漂亮的堆栈跟踪，而是打印出了toString-在NPE的情况下，它几乎没有用。

也许这就是您所经历的？

过去我们已经看到了相同的行为。事实证明，由于某种疯狂的原因，如果NullPointerException多次在代码中的同一位置发生，使用一段时间Log.error(String, Throwable)后将停止包含完整的堆栈跟踪。

尝试进一步查看日志。您可能会找到罪魁祸首。

编辑： 这个错误听起来很相关，但是很久以前就已修复，这可能不是原因。

这是一个解释：热点导致异常在生产中丢失了堆栈跟踪以及修复

我已经在Mac OS X上进行了测试

• Java版本“ 1.6.0_26”
• Java（TM）SE运行时环境（内部版本1.6.0_26-b03-383-11A511）

• Java HotSpot（TM）64位服务器VM（内部版本20.1-b02-383，混合模式）

  Object string = "abcd";
  int i = 0;
  while (i < 12289) {
      i++;
      try {
          Integer a = (Integer) string;
      } catch (Exception e) {
          e.printStackTrace();
      }
  }

对于此特定的代码片段，JVM决定使用预分配的异常的局限性是12288次迭代（+ frequency？）。

exception.toString 没有给你StackTrace，它只会返回

此throwable的简短描述。结果是以下内容的串联：

* the name of the class of this object
* ": " (a colon and a space)
* the result of invoking this object's getLocalizedMessage() method

使用exception.printStackTrace代替来输出StackTrace。

替代建议-如果您使用的是Eclipse，则可以在NullPointerException本身上设置一个断点（在Debug透视图中，转到“ Breakpoints”选项卡，然后单击带有！的小图标）

选中“ caught”和“ uncaught”两个选项-现在，当您触发NPE时，您将立即断点，然后可以逐步了解它的处理方式以及为什么没有得到堆栈跟踪。

toString()仅返回异常名称和可选消息。我建议打电话

exception.printStackTrace()

转储邮件，或者如果您需要血腥细节：

 StackTraceElement[] trace = exception.getStackTrace()

（关于您的代码是否正在调用，您的问题尚不清楚 printStackTrace()还是由日志处理程序完成，。）

以下是有关可能发生的情况的一些可能解释：

• 所使用的记录器/处理程序已配置为仅输出异常的消息字符串，而不是完整的堆栈跟踪。

• 您的应用程序（或某些第三方库）正在使用LOG.error(ex);而不是log4j Logger方法的2参数形式记录该异常。

• 信息来自与您认为不同的地方。例如，它实际上是某种第三方库方法，或者是较早的调试尝试遗留下来的一些随机内容。

• 正在记录的异常使一些方法变得难以理解，从而使stacktrace变得晦涩难懂。如果真是这样，该异常将不是真正的NullPointerException，而是某些NPE的自定义子类型，甚至是一些未连接的异常。

我认为，最后一种可能的解释是不太可能的，但是人们至少会考虑这样做以“防止”逆向工程。当然，只有这样才能真正为诚实的开发人员带来困难。

当您在项目中使用AspectJ时，可能会发生某些方面隐藏其堆栈跟踪的部分的情况。例如，今天我有：

java.lang.NullPointerException:
  at com.company.product.MyTest.test(MyTest.java:37)

通过Maven的surefire运行测试时，将打印此堆栈跟踪。

另一方面，在IntelliJ中运行测试时，将打印不同的堆栈跟踪：

java.lang.NullPointerException
  at com.company.product.library.ArgumentChecker.nonNull(ArgumentChecker.java:67)
  at ...
  at com.company.product.aspects.CheckArgumentsAspect.wrap(CheckArgumentsAspect.java:82)
  at ...
  at com.company.product.MyTest.test(MyTest.java:37)

这将输出异常，仅用于调试您应该更好地处理异常。

import java.io.PrintWriter;
import java.io.StringWriter;
    public static String getStackTrace(Throwable t)
    {
        StringWriter sw = new StringWriter();
        PrintWriter pw = new PrintWriter(sw, true);
        t.printStackTrace(pw);
        pw.flush();
        sw.flush();
        return sw.toString();
    }