Java8带来了新的Java.util.Optional类，它可以解决一些问题。至少可以说，它提高了代码的可读性，并且在公共API的情况下，使API的契约对客户端开发人员更加清晰。

它们是这样工作的：

给定类型（Fruit）的可选对象被创建为方法的返回类型。它可以是空的或包含Fruit对象：

public static Optional<Fruit> find(String name, List<Fruit> fruits) {
   for (Fruit fruit : fruits) {
      if (fruit.getName().equals(name)) {
         return Optional.of(fruit);
      }
   }
   return Optional.empty();
}

现在看看这段代码，我们在其中搜索给定Fruit实例的Fruit（水果）列表：

Optional<Fruit> found = find("lemon", fruits);
if (found.isPresent()) {
   Fruit fruit = found.get();
   String name = fruit.getName();
}

您可以使用map（）运算符对可选对象执行计算，或从中提取值。orElse（）允许您为缺少的值提供回退。

String nameOrNull = find("lemon", fruits)
    .map(f -> f.getName())
    .orElse("empty-name");

当然，检查空/空值仍然是必要的，但至少开发人员意识到该值可能是空的，忘记检查的风险是有限的。

在从头开始使用Optional构建的API中，只要返回值可能为空，并且仅在不能为空时返回纯对象（惯例），客户端代码可能会放弃对简单对象返回值的空检查。。。

当然，Optional也可以用作方法参数，在某些情况下，可能比5或10个重载方法更好地指示可选参数。

可选提供了其他方便的方法，例如允许使用默认值的orElse，以及与lambda表达式一起使用的ifPresent。

我邀请您阅读这篇文章（我撰写这个答案的主要来源），其中很好地解释了NullPointerException（以及一般的空指针）问题以及Optional带来的（部分）解决方案：Java Optional Objects。

避免不必要的空检查的方法很简单：

您需要知道哪些变量可以为空，哪些变量不能为空，并且您需要对给定变量属于哪一类有信心。

但是，尽管它可以说得很简单，但实现它却很困难。关键在于自信的部分，因为你如何确定变量不能为空？

对此没有快速的解决方法，但这里有一些提示：

干净的代码。能够推理一段代码的行为最重要的一点是，它是以易于理解的方式编写的。根据变量所代表的内容命名变量，根据它们所做的内容命名方法，应用单一责任原则（SOLID中的S：http://en.wikipedia.org/wiki/SOLID_（object-oriented_design），这意味着每一段代码都应该有一个单独的责任，并且不做任何其他事情）。一旦你的代码是干净的，那么你就更容易理解它，也更容易理解多个代码层。对于杂乱的代码，试图理解一个方法的作用可能会让你忘记当初为什么要读这个方法。（提示：阅读罗伯特·C·马丁的《清洁代码》）避免返回空值。如果空值会使程序无法正常运行，请改为抛出异常（确保添加适当的错误处理）。返回空值可能是可接受的情况，例如，尝试从数据库中获取对象。在这些情况下，编写处理空值的代码，并在您的耳朵后面记下，这里有可能返回空值的内容。处理返回的null值，使其尽可能接近返回null的方法的调用方（不要盲目地将其传递回调用链）永远不要将显式空值作为参数传递（至少不要跨类传递）。如果您曾经处于传递空参数是唯一选项的位置，那么创建一个不包含此参数的新方法是一种方法。验证您的输入！确定应用程序的“入口点”。它们可以从Web服务、REST服务、远程EJB类、控制器等所有内容。对于这些入口点中的每个方法，问问自己：“如果此参数为空，此方法是否正确执行？”如果答案为否，请添加Validate.notNull（someParam，“当someParam为空时无法运行！”）；。如果缺少必需的参数，这将引发IllegalArgumentException。在入口点进行这种类型的验证的好处是，您可以很容易地在从入口点执行的代码中假设该变量永远不会为空！此外，如果这失败了，在入口点，调试会比代码深处出现NullPointerException要容易得多，因为这样的失败只能意味着一件事：客户端没有向您发送所有必需的信息。在大多数情况下，您希望验证所有输入参数，如果您发现自己处于需要允许大量空值的位置，这可能是接口设计不良的标志，需要进行重构/添加以满足客户机的需要。使用集合时，返回一个空集合而不是空集合！使用数据库时，请使用非空约束。这样，您就知道从数据库中读取的值不能为空，并且不必检查它。构造代码并坚持执行。这样做可以让您对代码的行为做出假设，例如，如果应用程序的所有输入都经过验证，那么您可以假设这些值永远不会为空。如果您还没有这样做，请编写代码的自动测试。通过编写测试，您将对代码进行推理，并且您也将更加确信它确实做到了它应该做的事情。此外，自动化测试通过让您立即知道这段代码没有做以前的事情来防止重构过程中的错误。

当然，您仍然需要进行空检查，但它可以降到最低限度（即，知道您可能会得到空值，而不是到处都是空值）。当谈到空检查时，我实际上更喜欢使用三元运算符（但要小心使用，当您开始嵌套它们时，它们会变得非常混乱）

public String nullSafeToString(final Object o) {
    return o != null ? o.toString() : "null";
}

还有一种选择：

下面的简单函数有助于隐藏空检查（我不知道为什么，但我没有发现它是同一个公共库的一部分）：

public static <T> boolean isNull(T argument) {
    return (argument == null);
}

你现在可以写了

if (!isNull(someobject)) {
    someobject.doCalc();
}

这是IMO更好的表达方式！=无效的

对于每个Java开发人员来说，这是一个非常常见的问题。因此，Java8中有官方支持来解决这些问题，而不会产生混乱的代码。

Java 8引入了Java.util.Optional＜T＞。它是一个可以容纳或不容纳非空值的容器。Java8提供了一种更安全的方法来处理在某些情况下值可能为空的对象。它的灵感来自Haskell和Scala的想法。

简而言之，Optional类包含显式处理值存在或不存在的情况的方法。然而，与空引用相比，Optional＜T＞类的优点是，当值不存在时，强制您考虑情况。因此，可以防止意外的空指针异常。

在上面的示例中，我们有一个家庭服务工厂，它向家庭中可用的多个设备返回句柄。但这些服务可能可用或不可用；这意味着它可能会导致NullPointerException。与其在使用任何服务之前添加null if条件，不如将其包装到Optional＜service＞中。

包装到选项<T>

让我们考虑一种从工厂获取服务引用的方法。与其返回服务引用，不如用Optional包装它。它让API用户知道返回的服务可能不可用/不起作用，可以防御性地使用

public Optional<Service> getRefrigertorControl() {
      Service s = new  RefrigeratorService();
       //...
      return Optional.ofNullable(s);
   }

如您所见，Optional.Nullable（）提供了一种简单的方式来包装引用。还有其他方法可以获取Optional的引用，Optional.empty（）和Optional.of（）。一种方法用于返回空对象而不是重新调整null，另一种方法分别包装不可为null的对象。

那么，如何避免空检查呢？

包装引用对象后，Optional提供了许多有用的方法来调用包装引用上的方法，而无需NPE。

Optional ref = homeServices.getRefrigertorControl();
ref.ifPresent(HomeServices::switchItOn);

Optional.ifRepresent调用具有引用的给定Consumer（如果它是非空值）。否则，它什么也不做。

@FunctionalInterface
public interface Consumer<T>

表示接受单个输入参数但不返回结果的操作。与大多数其他功能界面不同，Consumer预期通过副作用进行操作。它很干净，很容易理解。在上面的代码示例中，如果Optional保持引用为非空，则调用HomeService.switchOn（Service）。

我们经常使用三元运算符来检查空条件，并返回替代值或默认值。可选提供了另一种处理相同条件而不检查null的方法。Optional.orElse（defaultObj）如果Optional具有空值，则返回defaultObj。让我们在示例代码中使用它：

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

现在HomeServices.get（）做了同样的事情，但方式更好。它检查服务是否已初始化。如果是，则返回相同的或创建新的new服务。可选＜T＞。或Else（T）有助于返回默认值。

最后，这里是我们的NPE以及无空检查代码：

import java.util.Optional;
public class HomeServices {
    private static final int NOW = 0;
    private static Optional<HomeServices> service;

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

public Optional<Service> getRefrigertorControl() {
    Service s = new  RefrigeratorService();
    //...
    return Optional.ofNullable(s);
}

public static void main(String[] args) {
    /* Get Home Services handle */
    Optional<HomeServices> homeServices = HomeServices.get();
    if(homeServices != null) {
        Optional<Service> refrigertorControl = homeServices.get().getRefrigertorControl();
        refrigertorControl.ifPresent(HomeServices::switchItOn);
    }
}

public static void switchItOn(Service s){
         //...
    }
}

完整的帖子是NPE以及空检查免费代码…真的吗？。

只是永远不要使用null。不要允许。

在我的类中，大多数字段和局部变量都有非空的默认值，我在代码中的任何地方都添加了契约语句（总是在断言上），以确保这是强制执行的（因为它比让它作为NPE出现然后必须解析行号等更简洁、更具表达力）。

一旦我采用了这种做法，我注意到问题似乎会自行解决。你会在开发过程中很早就发现事情，只是偶然发现自己有一个弱点。。更重要的是。。它有助于封装不同模块的关注点，不同模块可以相互“信任”，不再在代码中添加if=nullelse结构！

这是一种防御性编程，从长远来看，代码会更加干净。始终对数据进行净化，例如在这里通过强制执行严格的标准，问题就会消失。

class C {
    private final MyType mustBeSet;
    public C(MyType mything) {
       mustBeSet=Contract.notNull(mything);
    }
   private String name = "<unknown>";
   public void setName(String s) {
      name = Contract.notNull(s);
   }
}


class Contract {
    public static <T> T notNull(T t) { if (t == null) { throw new ContractException("argument must be non-null"); return t; }
}

合同就像是小型单元测试，即使在生产中也始终在运行，当事情失败时，你知道原因，而不是随机的NPE，你必须设法弄清楚。

！=的另一种选择空检查是（如果你无法在设计上摆脱它）：

Optional.ofNullable(someobject).ifPresent(someobject -> someobject.doCalc());

or

Optional.ofNullable(someobject).ifPresent(SomeClass::doCalc);

SomeClass是某个对象的类型。

但是，您无法从doCalc（）获取返回值，因此仅对void方法有用。