使用Java8已经6个多月了，我对新的API更改非常满意。我仍然不确定的一个方面是何时使用可选。我似乎想在任何地方都使用它，有些东西可能是null，而不是任何地方
似乎在很多情况下我都可以使用它，我不确定它是否增加了好处（可读性/空安全性）或只是增加了额外的开销
所以，我举了几个例子，我想听听社区对可选是否有益的想法
1-当方法可以返回null时，作为公共方法返回类型：
公共可选<；Foo>；findFoo（字符串id）；
2-当参数可能为null时，作为方法参数：
公共食物剂量仪（字符串id，可选<；Bar>；BAROOPTIONAL）；
3-作为bean的可选成员：
公共课程手册{
私人列表<；页面>；页面；
私有可选<；索引>；索引；
}
4-在集合中：
总的来说，我不认为：
列表<；可选<；Foo>&燃气轮机；
添加任何内容-特别是因为可以使用filter（）删除null值等，但是可选在集合中有什么好的用途吗
有我错过的案子吗
Optional的主要设计目标是为返回值的函数提供一种方法，以指示没有返回值。请参见此讨论这允许调用方继续一系列流畅的方法调用。
这与OP问题中的用例1最为接近。尽管如此，缺少值比null更精确，因为类似IntStream.findFirst的内容永远不会返回null
对于用例#2，将可选参数传递给一个方法，这是可行的，但相当笨拙。假设您有一个方法，该方法接受一个字符串，后跟一个可选的第二个字符串。接受一个可选的作为第二个参数将产生如下代码：
foo（"；bar"；，可选。of（"；baz"；）；
foo（“bar”，可选.empty（））；
即使接受null也更好：
foo（“bar”和“baz”）；
foo（“bar”，null）；
最好是使用一个重载方法，该方法接受单个字符串参数，并为第二个参数提供默认值：
foo（“bar”和“baz”）；
foo（“酒吧”）；
这确实有局限性，但它比上述任何一种都好
用例#3和#4在类字段或数据结构中具有可选的被认为是对API的滥用。首先，它违背了顶部所述的Optional的主要设计目标。其次，它没有增加任何价值
有三种方法可以处理可选中缺少值的问题：提供替换值、调用函数以提供替换值或引发异常。如果要存储到字段中，则应在初始化或分配时执行此操作。如果您要向列表中添加值，如OP所述，您还可以选择不添加值，从而；“扁平化”；删除缺少的值
我肯定有人会想出一些人为的例子，他们真的想在字段或集合中存储可选的，但一般来说，最好避免这样做