Java 8th 可以看做是 java 版本更新迭代过程中变化最大的几个版本之一（与时俱进，方能不灭），但是经过这么多年的发展和迭代，java 的源码俨然已是一个庞然大物，要在这样庞大的体积上大动干戈必定不易。所以当第一次看到默认接口方法的时候，我第一感觉就是这是设计人员在填自己之前挖的坑。

从前几篇的讲解中我们知道 8th 在现有的接口上添加了许多方法，比如 List 的 sort(Comparator<? super E> c) 方法。如果按照 8th 之前接口的设计思路，当给一个接口添加方法声明的时候，实现该接口的类都必须为该新添加的方法添加相应的实现（或将自己设置为抽象类）。考虑兼容性这样是不可取的，所以说这是一个坑，而新的特性又要求不得不为接口添加一些新的方法，为了兼得鱼和熊掌，设计人员提出了默认接口方法的概念。

第一次接触到流式数据处理的时候，第一感觉是流式数据处理让集合操作变得简洁了许多，通常我们需要多行代码才能完成的操作，借助于流式数据处理可以在一行中实现。比如我们希望对一个包含整数的集合筛选出所有的偶数，并将其封装成为一个新的集合返回，那么在 8th 之前，我们需要通过如下代码实现：

1
2
3
4
5
6

List<Integer> evens = new ArrayList<>();
for (final Integer num : nums) {
    if (num % 2 == 0) {
        evens.add(num);
    }
}

NullPointException 可以说是所有 java 程序员都遇到过的一个异常，虽然 java 从设计之初就力图让程序员脱离指针的苦海，但是指针确实是实际存在的，而 java 设计者也只能是让指针在 java 语言中变得更加简单、易用，而不能完全的将其剔除，所以才有了我们日常所见到的关键字 null。

空指针异常是一个运行时异常，对于这一类异常，如果没有明确的处理策略，那么最佳实践在于让程序早点挂掉，但是很多场景下不是开发人员没有具体的处理策略，而是根本没有意识到空指针异常的存在。当异常真的发生的时候，处理策略也很简单，在存在异常的地方添加一个 if 语句判定即可，但是这样的应对策略会让我们的程序出现越来越多的 null 判定。

Lambda 表达式是 java 8th 给我们带来的几个重量级新特性之一，借用 lambda 表达式可以让我们的程序设计更加简洁。最近新的项目摒弃了 6th 版本，全面基于 8th 进行开发，本文将探讨 行为参数化 、lambda 表达式 ，以及 方法引用 等知识点。

一. 行为参数化

行为参数化简单的说就是将方法的逻辑以参数的形式传递到方法中，方法主体仅包含模板类通用代码，而一些会随着业务场景而变化的逻辑则以参数的形式传递到方法之中，采用行为参数化可以让程序更加的通用，以应对频繁变更的需求。

需求缘起

几乎所有的业务系统，都有生成一个记录标识的需求，例如：

1. 消息标识：message-id
2. 订单标识：order-id
3. 帖子标识：tiezi-id

这个记录标识往往就是数据库中的唯一主键，数据库上会建立聚集索引（cluster index），即在物理存储上以这个字段排序。

在分布式系统中著有 CAP 理论，该理论由加州大学伯克利分校的 Eric Brewer 教授提出，阐述了在一个分布式系统中不可能同时满足一致性（ C onsistency）、可用性（ A vailability），以及分区容错性（ P artition Tolerance）。

• 一致性 ：在分布式系统中数据往往存在多个副本，一致性描述的是这些副本中的数据在内容和组织上的一致。
• 可用性 ：描述系统对用户的服务能力，所谓可用是指在用户能够容忍的时间范围内返回用户期望的结果。
• 分区容错性 ：分布式系统通常由多个节点构成，由于网络是不可靠的，所以存在分布式集群中的节点因为网络通信故障导致被孤立成一个个小集群的可能性，即网络分区，分区容错性要求在出现网络分区时系统仍然能够对外提供一致性的可用服务。

ConcurrentHashMap 是线程安全的 HashMap。此前，HashTable 一直被认为是线程安全的 HashMap，ConcurrentHashMap 相对于 HashTable 采用了 锁分段机制 ，即将原本对整个对象加锁的实现进行粒度细化。这也是源于 HashMap 基本的存储特性，因为许多读写请求都是被哈希到了互相独立的区域，这种情况下即使并发读写也不会相互影响，更不会有线程安全问题，而对于操作加全局锁的实现方式显然是浪费了这一天然的并发优势，我们需要加锁的位置是真正存在竞争的地方，而分段锁很好的利用了这一特点。

这周小组内的学习是探讨 java 异常处理的最佳实践，今天周末，外面太闷，宅在家里对 java 的异常处理的个人立即做一个总结，如有不对的地方欢迎指正~

一. 谈谈个人对 java 异常处理的看法

维基百科对于异常处理的定义是：

异常处理，是编程语言或计算机硬件里的一种机制，用于处理软件或信息系统中出现的异常状况（即超出程序正常执行流程的某些特殊条件）。

每一个 java 程序员都知道日志对于任何一个 java 应用程序，尤其是服务端程序是至关重要的，而很多程序员也已经熟悉各种不同的日志库，如 java.util.logging、Apache log4j，以及 logback 等。但如果你还不知道 slf4j（Simple logging facade for Java）的话，那么是时候去在你项目中学习使用 slf4j 了。

在这篇文章中，我们将学习为什么使用 slf4j 比 log4j 或者 java.util.logging 要优秀。自从上次我写 java 程序员的 10 个日志技巧已经有一段时间了，我已经不记得我写的关于日志的一切了。

对于刚接触同步器的同学来说，CountDownLatch 和 CyclicBarrier 应该是两个比较容易混淆的组件，它们都能表示让多个线程等待某个特定事件的语义，不过在功能上还是存在一些差别，实际上它们的 主要区别在于参与的线程是否需要阻塞相互等待一起到达事件的位置，然后再继续向下执行 。官方对这两个组件的定义分别如下：

• CountDownLatch : A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.
• CyclicBarrier : A synchronization aid that allows a set of threads to all wait for each other to reach a common barrier point.

看了之后是不是更加迷惑？下面我们通过举例来理清这二者的区别。