JAVA 8 的新特性
Java 8 早在2014年3月份就已经有了，然而这是一次大的更新，如今的安卓框架就在使用java 8 的 Lambda表达式，如今正被越来越多的人发现它的优点与好处，也成为了未来的趋势。
Java 8 的优点：
速度更快
代码更少(增加新语法Lambda 表达式)
强大的Stream API
便于并行
最大化减少空指针异常 Optional
首先速度更快体现在很多方面，比如对于底层的数据结构进行了一定的更新和改动，对JVM 垃圾回收机制，也就是内存结构也做了一定的改变，对于并行进行了拓展和支持。对于底层的数据结构的更新，我们知道对于底层的算法结构，最核心的就是HashMap，我们首先可以回顾一下，原来HashMap的样子，我们为什么要采用哈希表，假设没有哈希表
如图，我们每一次导入元素都需要与里面所有的元素进行equals 对比，假设我往里面导入10000个元素，每个元素再一一对比，效率会非常低，于是java工程师采用了哈希表(哈希算法)，其在底层是一个数组，数组中存储的都是一个个的Encrypt,Map这个哈希表默认的大小是16，如果我们采用哈希表，我们往里面添加一个对象的话，首先会调用这个对象的hashCode的方法，然后根据哈希算法对hashCode 方法进行一个运算，然后生成了一个数组的索引值，然后根据这个索引值找到相应的位置，查看是否有对象在，如果没有就直接存储。
相应的也会可能出现一种情况，发现位置内有对象，然后就比较两个对象的内容相同，那么它所对应的键的值就会覆盖原先键所对应的值，最终保留一个。
还有一种情况通过对比发现内容不一样，这个时候在1.7版本会把后加的放到前面形成链表结构，这种情况我们称它为碰撞，这种情况是我们应该尽可能避免的，因为如果元素过多，导入对象同样做多次equals最后依然会影响到效率
我们能做的或许就是把hashCode方法和equals 方法写的严谨一些，但是这仍然无法完全避免发生这种碰撞，为了避免链表过长，这个时候HashMap 提供了了加载因子，其默认值为0.75，意思是当这个对象到达的这个哈希表的容量的百分之75的时候就进行扩容，然后对链表的每个内容进行重新排序，放到新的扩容以后的位置 ，从而减少了碰撞的几率，然而这依旧无法避免碰撞的发生，影响效率，于是JDK8引入了红黑树，这时的哈希表不再是数组加链表了，而是数组加链表加红黑树，什么时候会变红黑树呢，它并不是一开始就会使用的，条件是当碰撞的链表的长度大于8，且总容量大于64，会把链表转变为红黑树，不再直接添加到链表的末尾，而是通过对比大小存放位置
通过转换为红黑树，除了添加速度慢，其他速度都提高了，从而提高了效率。
哈希表变了，从而Hashset 也变了，还有ConcurrentHashMap,在JDK7 的时候它
ConcurrentLevel=16 , 采用锁分段机制，每一个段对应一个表，在JDK 8以后段基本没有用了，改成了CAS算法 (无锁算法)CAS 支持系统底层算法效率要高。
JDK8速度更快还体现在，它对底层的内存结构也进行了优化
原来画内存图，方法区实际上是堆内永久区的一部分，存储加载类的一些虚拟机，核心类库，永久区的内容几乎不会被垃圾回收机制回收，早在1.7之前，除了Oracle-SUN Hotspot 其他的JVM 厂商(Oracle JRocket、IBM J9 JVM 、Taobao JVM)就把永久区剥离出去了。
JDK 8 以后 永久区就被彻底的剥离方法区改为MetaSpace 元空间，它与原来最大的不同是它使用的是物理内存，当元空间超标的时候 垃圾回收机制才会开始回收，因为物理内存很大，所以垃圾回收机制启动的概率变低了，从而在内存结构上提升了效率
配置方法更改
