常见的方法是这样的:
没有理由对没有奶酪可供购买的情况进行特殊处理。这样做需要额外的代码在客户端处理可能为空的返回值，例如:
在几乎每次使用返回null来代替空集合或数组的方法时，都需要使用这种绕行。它很容易出错，因为编写客户机的程序员可能忘记编写特殊情况的代码来处理null返回。这样的错误可能会被忽略多年，因为这样的方法通常返回一个或多个对象。此外，在空容器中返回null会使返回容器的方法的实现复杂化。
有时有人认为，空返回值比空集合或数组更可取，因为它避免了分配空容器的开销。这个论点有两点是不成立的。首先，在这个级别上担心性能是不明智的，除非度量表明所讨论的分配是性能问题的真正贡献者(item67 )。第二，返回空集合和数组而不分配它们是可能的。下面是返回可能为空的集合的典型代码。通常，这就是你所需要的:
如果有证据表明分配空集合会损害性能，可以通过返回相同不可变的空集合来避免重复分配，作为不可变对象，可以自由共享( item17)。这是用代码来实现这个方法，使用 Collections.emptyList 方法。如果你返回一个set，使用Collections.emptySet。如果要返回map，使用Collections.emptyMap。但是记住，这是一种优化，很少需要。如果你认为你需要它，测量一下前后的表现，确保它确实有帮助:
数组的情况与集合的情况相同。永远不要返回null而不是零长度的数组。通常，您应该简单地返回一个正确长度的数组，它可能是零。注意，我们将一个零长度的数组传递到toArray方法中，以指示所需的返回类型，即Cheese[]:
如果你认为分配零长度数组会损害性能，你可以重复返回相同的零长度数组，因为所有的零长度数组都是不可变的:
在优化版本中，我们将相同的空数组传递到每个toArray调用中，当cheesesInStock为空时，这个数组将从getCheeses返回。不要为了提高性能而预先分配传递给toArray的数组。研究表明，这样做会适得其反[Shipilev16]:
总之，永远不要返回空数组或集合。它使您的API更难以使用，更容易出错，并且没有性能优势。
本文写于2019.7.18，历时1天
