在过去的几年中，我一直使用Java 8 进行了很多的编码工作，用于开发 新应用 和 迁移遗留应用 ，我觉得是时候写一些有用的”最佳实践”。我个人不喜欢”最佳实践”这个术语，因为它意味着“一刀切”的解决方案，当然编码工作是不会这样的–这是因为我们开发人员会想出适合我们的方案。但我发现我对Java8特别的喜欢，它让我的生活更轻松一点，所以我想就此话题展开讨论。
Optional
Optional 是一个被严重低估的功能, 它消除了很多困扰着我们的 NullPointerExceptions。它在代码边界（包括你调用和提供 API）处理上特别有用，因为它允许你和你调用的代码说明程序运行的期望结果。
然而，如果没有必要的思考和设计，那么就会导致一个小变化而影响大量的类，也会导致可读性变差。这里有一些关于如何高效使用Optional的提示。
Optional 应该只用于返回类型
…不能是参数和属性. 阅读 这个博客 了解怎样使用 Optional。 幸运的是, IntelliJ IDEA 在打开 inspection 功能的情况下会检查你是否遵循了这些建议。
<img src="https://pic1.zhimg.com/v2-fdc9dd4537d3de90958c3078c6eb6f10_b.png" data-rawwidth="550" data-rawheight="104" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic1.zhimg.com/v2-fdc9dd4537d3de90958c3078c6eb6f10_r.png">可选值应该在使用的地方进行处理. IntelliJ IDEA的建议可以防止你不恰当的使用Optional, 所以你应该立即处理你发现的不恰当使用Optional。(根据自己的理解翻译)
可选值应该在使用的地方进行处理. IntelliJ IDEA的建议可以防止你不恰当的使用Optional,
所以你应该立即处理你发现的不恰当使用Optional。(根据自己的理解翻译)
<img src="https://pic2.zhimg.com/v2-d7f30376b62e663bb61246d69d2c2f81_b.png" data-rawwidth="550" data-rawheight="61" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic2.zhimg.com/v2-d7f30376b62e663bb61246d69d2c2f81_r.png">
你不应该简单的调用 get()
Optinal的目的是为了表示此值有可能为空，且让你有能力来应付这种情况。因此，在使用值之前进行检查是非常重要的。在某些情况下简单的调用get()而没有先使用isPresent()进行检查是一样会导致空指针问题。幸运的是，IntelliJ IDEA 任然会检查出这个问题并警告你。 <img src="https://pic4.zhimg.com/v2-61fe2fa46341f2ee9b1251545b734aff_b.png" data-rawwidth="550" data-rawheight="60" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic4.zhimg.com/v2-61fe2fa46341f2ee9b1251545b734aff_r.png">
有可能是一个更优雅的方式
isPresent() 与 get() 结合 使用的技巧 …
<img src="https://pic2.zhimg.com/v2-ef96880905e5fee1c895548aadb61dc9_b.png" data-rawwidth="550" data-rawheight="99" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic2.zhimg.com/v2-ef96880905e5fee1c895548aadb61dc9_r.png">但还有更优雅的解决方案。你可以使用 orElse方法来使得当它为null时给出一个代替的值。
但还有更优雅的解决方案。你可以使用 orElse方法来使得当它为null时给出一个代替的值。 <img src="https://pic3.zhimg.com/v2-c6db648de988a60200002d9ba0248a8a_b.png" data-rawwidth="550" data-rawheight="36" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic3.zhimg.com/v2-c6db648de988a60200002d9ba0248a8a_r.png">或者使用 orElseGet方法来处理上述相同情况。这个例子和上面的看起来好像一样，但本例是可以调用 supplier接口的 实现 ,，因此如果它是一个高开销的方法，可以使用 lambda 表达式来获得更好的性能。
或者使用 orElseGet方法来处理上述相同情况。这个例子和上面的看起来好像一样，但本例是可以调用 supplier接口的
实现 ,，因此如果它是一个高开销的方法，可以使用 lambda 表达式来获得更好的性能。 <img src="https://pic4.zhimg.com/v2-fcb70bd400149ea977069dcecfb94487_b.png" data-rawwidth="550" data-rawheight="39" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic4.zhimg.com/v2-fcb70bd400149ea977069dcecfb94487_r.png">
使用Lambda表达式
Lambda 表达式 是 Java 8 的卖点之一.。即使你还没有使用过Java 8， 到目前你也可能有一些基本的了解。但在Java编程中还是一种新的方式，它也不是明显的”最佳实践” 。 这里有一些我遵循的指南。
保持简短
函数式程序员更愿意使用较长的lambda 表达式，但我们这些仅仅使用Java很多年的程序员来说更容易保持lambda 表达式的短小。你甚至更喜欢把它们限制在一行，更容易把较长的表达式 重构 到一个方法中。
<img src="https://pic1.zhimg.com/v2-fb972284c1dca23aac4f588c163ea394_b.png" data-rawwidth="548" data-rawheight="164" class="origin_image zh-lightbox-thumb" width="548" data-original="https://pic1.zhimg.com/v2-fb972284c1dca23aac4f588c163ea394_r.png">把它们变成一个方法引用， 方法引用看起来有一点陌生，但却值得这样做，因为在某些情况有助于提高可读性，后面我再谈可读性。
把它们变成一个方法引用， 方法引用看起来有一点陌生，但却值得这样做，因为在某些情况有助于提高可读性，后面我再谈可读性。
<img src="https://pic2.zhimg.com/v2-ebc627e4c3331e7fa2f7ca7a5af05825_b.png" data-rawwidth="390" data-rawheight="71" class="content_image" width="390">
明确的
(作者应该想要表达的是: 参数命名规范，要有意义；有更好的翻译请修正)
lambda 表达式中类型信息已经丢失了，因此你会发现包含类型信息的参数会更有用。
<img src="https://pic4.zhimg.com/v2-971f11c2a8f39157d413b82fbb584b93_b.png" data-rawwidth="550" data-rawheight="21" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic4.zhimg.com/v2-971f11c2a8f39157d413b82fbb584b93_r.png">
如你所见，这样会比较麻烦。因此我更喜欢给参数一个更有意义的命名。当然，你做与否， IntelliJ IDEA 都会让你看到参数的类型信息。
<img src="https://pic4.zhimg.com/v2-5b548fa07053174380a74db597ca04c7_b.png" data-rawwidth="550" data-rawheight="58" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic4.zhimg.com/v2-5b548fa07053174380a74db597ca04c7_r.png">即使是在函数式接口的lambda 表达式中:
即使是在函数式接口的lambda 表达式中: <img src="https://pic1.zhimg.com/v2-5c5e3f78fd72f6813b495f358e8fafc4_b.png" data-rawwidth="550" data-rawheight="38" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic1.zhimg.com/v2-5c5e3f78fd72f6813b495f358e8fafc4_r.png">
针对 Lambda 表达式进行设计
我认为lambda表达式有点像 泛型 – 泛型,我们经常使用它们 (例如, 给 List<> 添加类型信息 )，但不常见的是我们把一个方法或类泛型化 (如: Person<T> )。同样的, 它就像我们使用通过lambdas包装的 Streams API，但对我们来说更罕见的是创建一个需要 lambda 表达式参数的方法。
IntelliJ IDEA 可以帮助你引入一个函数化的参数
这里让你可以使用 Lambda 表达式而非对象来 创建一个参数 。这个功能的好处在于其建议使用一个已有的 函数接口 来匹配这个规范。
&amp;amp;amp;lt;img src="https://pic1.zhimg.com/v2-1b9a127eb6600620852cff61afc4b9d0_b.png" data-rawwidth="550" data-rawheight="111" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic1.zhimg.com/v2-1b9a127eb6600620852cff61afc4b9d0_r.png"&amp;amp;amp;gt;
这个将引导我们
使用已有的函数接口
当开发者越来越熟悉 Java 8 代码时，我们会知道使用例如 Supplier 和 Consumer 这样的接口会发生什么，但是单独再创建一个 ErrorMessageCreator 会让我们很诧异并且很浪费时间。你可以翻阅 function package 来查看系统本身已经给我们准备了什么。
为函数接口添加 @FunctionalInterface 注解
如果你真的需要创建自己的函数接口，那么就需要用这个 @FunctionalInterface 注解。这个注解似乎没多大用处，但是 IntelliJ IDEA 会在接口不满足这个注解要求的情况下予以提示。例如你没有指定要继承的方法：
&amp;amp;amp;lt;img src="https://pic1.zhimg.com/v2-5dc6e3e41a46a66e3f78236bc0a24390_b.png" data-rawwidth="346" data-rawheight="94" class="content_image" width="346"&amp;amp;amp;gt;指定太多的方法：
指定太多的方法：
&amp;amp;amp;lt;img src="https://pic4.zhimg.com/v2-6e6b6f30298ecee88fb39be2126e3f13_b.png" data-rawwidth="550" data-rawheight="110" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic4.zhimg.com/v2-6e6b6f30298ecee88fb39be2126e3f13_r.png"&amp;amp;amp;gt;在类中使用注解而不是在接口：
在类中使用注解而不是在接口： &amp;amp;amp;lt;img src="https://pic2.zhimg.com/v2-5191d39792ee764bdc302b5bf4ffc161_b.png" data-rawwidth="393" data-rawheight="88" class="content_image" width="393"&amp;amp;amp;gt;
Lambda 表达式可用于任意只包含单个抽象方法的接口中，但是不能用于满足该要求的抽象类。看似不符合逻辑，但实际要求必须如此。
Streams
Stream API 是Java 8的另一大卖点, 我认为到现在为止，我们仍然不知道这会对我们的编码方式有多大改变．但我发现这是一个好坏参半的功能。
流式风格
就我个人而言，更喜欢使用流式风格．当然你不必也这么做, 但我发现它帮助了我：
- 一眼就能看出有哪些操作，它的执行顺序是什么
- 更方便调试（虽然IntelliJ IDEA提供了 在包含lambda表达式的行上设置断点的能力 ，为了更方便调试，把它拆分到不同的行上）* 在测试的时候允许取消一个操作
- 在调试或测试是，可以很方便的插入peek()
&amp;amp;amp;lt;img src="https://pic1.zhimg.com/v2-7908083057df1b705ba01fa1668e6534_b.png" data-rawwidth="390" data-rawheight="149" class="content_image" width="390"&amp;amp;amp;gt;在我看来这样写很简洁。但是使用这种方法并没有给我们节省多少代码行。你可能需要调整代码格式化设置让代码看起来更加清晰。
在我看来这样写很简洁。但是使用这种方法并没有给我们节省多少代码行。你可能需要调整代码格式化设置让代码看起来更加清晰。
&amp;amp;amp;lt;img src="https://pic2.zhimg.com/v2-fac7e00a8782660290fab8502622a1c1_b.png" data-rawwidth="550" data-rawheight="179" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic2.zhimg.com/v2-fac7e00a8782660290fab8502622a1c1_r.png"&amp;amp;amp;gt;
使用方法引用
是的，你需要一点时间来适应这个奇怪的语法。但如果使用恰当，真的可以提升代码的可读性，看看下面代码：
&amp;amp;amp;lt;img src="https://pic2.zhimg.com/v2-91afa8bfd1db62042cb9a637211b632d_b.png" data-rawwidth="542" data-rawheight="67" class="origin_image zh-lightbox-thumb" width="542" data-original="https://pic2.zhimg.com/v2-91afa8bfd1db62042cb9a637211b632d_r.png"&amp;amp;amp;gt;以及使用
以及使用 Objects 类的辅助方法：
&amp;amp;amp;lt;img src="https://pic4.zhimg.com/v2-997a5e0839b1aa69c48b1ce1007a892f_b.png" data-rawwidth="546" data-rawheight="72" class="origin_image zh-lightbox-thumb" width="546" data-original="https://pic4.zhimg.com/v2-997a5e0839b1aa69c48b1ce1007a892f_r.png"&amp;amp;amp;gt;后面一段代码更加的明确可读。IntelliJ IDEA 通常会知道怎么将一个 Lambda 表达式进行折叠。
后面一段代码更加的明确可读。IntelliJ IDEA 通常会知道怎么将一个 Lambda 表达式进行折叠。
&amp;amp;amp;lt;img src="https://pic3.zhimg.com/v2-6bb2ccf60ab978a1e44f289b0d8ab7da_b.png" data-rawwidth="539" data-rawheight="81" class="origin_image zh-lightbox-thumb" width="539" data-original="https://pic3.zhimg.com/v2-6bb2ccf60ab978a1e44f289b0d8ab7da_r.png"&amp;amp;amp;gt;
当对集合进行元素迭代时，尽可能的使用 Streams API
或者用新的集合方法，例如 forEach . IntelliJ IDEA 会建议你这么做：
&amp;amp;amp;lt;img src="https://pic4.zhimg.com/v2-822a6c824597705b6173a81a1ce787fb_b.png" data-rawwidth="498" data-rawheight="96" class="origin_image zh-lightbox-thumb" width="498" data-original="https://pic4.zhimg.com/v2-822a6c824597705b6173a81a1ce787fb_r.png"&amp;amp;amp;gt;一般来说使用 Streams API 比起循环和 if 语句组合来得更加直观，例如：
一般来说使用 Streams API 比起循环和 if 语句组合来得更加直观，例如：
&amp;amp;amp;lt;img src="https://pic2.zhimg.com/v2-f467d4ba917453b7dca58356545c487d_b.png" data-rawwidth="524" data-rawheight="132" class="origin_image zh-lightbox-thumb" width="524" data-original="https://pic2.zhimg.com/v2-f467d4ba917453b7dca58356545c487d_r.png"&amp;amp;amp;gt;IntelliJ IDEA 会建议这样的写法进行重构：
IntelliJ IDEA 会建议这样的写法进行重构：
&amp;amp;amp;lt;img src="https://pic1.zhimg.com/v2-c329e35cbd1bec9d7531afcbd27a5a44_b.png" data-rawwidth="550" data-rawheight="65" class="origin_image zh-lightbox-thumb" width="550" data-original="https://pic1.zhimg.com/v2-c329e35cbd1bec9d7531afcbd27a5a44_r.png"&amp;amp;amp;gt;我做过的性能测试显示这种重构带来的结果比较奇怪，难以预测，有时候好，有时候坏，有时候没区别。一如既往的，如果你的应用对性能问题非常在意，请认真的进行衡量。
我做过的性能测试显示这种重构带来的结果比较奇怪，难以预测，有时候好，有时候坏，有时候没区别。一如既往的，如果你的应用对性能问题非常在意，请认真的进行衡量。
遍历数组时请用 for 循环
然后，使用 Java 8 并不意味着你一定要使用流 API 以及集合的新方法。IntelliJ IDEA 会建议一些做法改用流的方式重构，但你不一定非得接受 (记住 inspections can be suppressed 或者 turned off ).
特别是对一个原始类型的小数组时，使用 for 循环的性能是最好的，而且代码更具可读性（至少对 Streams API 的新手来说是这样）：
&amp;amp;amp;lt;img src="https://pic2.zhimg.com/v2-2c4cf62865f6eb59213a786649c2fbd5_b.png" data-rawwidth="360" data-rawheight="100" class="content_image" width="360"&amp;amp;amp;gt;
任何的技巧和提示都不是一成不变的，你应该自己决定哪里需要使用 Streams API ，而哪里还用循环操作。
最后
我每天都在发现一些新的东西，有时候我的偏好会有所变化。例如我过去会讨厌方法的引用。非常期待倾听你的建议。
原文：Java 8 最佳技巧
