Java 8无人谈及的八大成果
副标题#e#
时间戳锁
一直以来，多线程代码是处事器开拓人员的毒药（问问Oracle的Java语言架构师和并行开拓大家Brian Goetz）。Java的焦点库不绝插手各类巨大的用法来淘汰会见共享资源时的线程期待时间。个中之一就是经典的读写锁（ReadWriteLock），它让你把代码分成两部门：需要互斥的写操纵和不需要互斥的读操纵。
外貌上看起来很不错。问题是读写锁有大概是极慢的（最多10倍），这已经和它的初志相悖了。Java 8引入了一种新的读写锁——叫做时间戳锁。好动静是这个家伙真的很是快。坏动静是它利用起来更巨大，有更多的状态需要处理惩罚。而且它是不行重入的，这意味着一个线程有大概跟本身死锁。
时间戳锁有一种“乐观”模式，在这种模式下每次加锁操纵城市返回一个时间戳作为某种权限凭证；每次解锁操纵都需要提供它对应的时间戳。假如一个线程在请求一个写操纵锁的时候，这个锁可巧已经被一个读操纵持有，那么这个读操纵的解锁将会失效（因为时间戳已经失效）。这个时候应用措施需要从新再来，也许要利用灰心模式的锁（时间戳锁也有实现）。你需要本身搞定这一切，而且一个时间戳只能解锁它对应的锁——这一点必需很是小心。
下面我们来看一下这种锁的实例——
long stamp = lock.tryOptimisticRead(); // 非阻塞路径——超等快
work(); // 我们但愿不要有写操纵在这时产生
if (lock.validate(stamp)){
//乐成！没有写操纵滋扰
}
else {
//必定同时有别的一个线程得到了写操纵锁，改变了时间戳
//懒汉说——我们切换到开销更大的锁吧
stamp = lock.readLock(); //这是传统的读操纵锁，会阻塞
try {
//此刻不行能有写操纵产生了
work();
}
finally {
lock.unlock(stamp); // 利用对应的时间戳解锁
}
}
并发加法器
Java 8另一个精彩的成果是并发“加法器”，它对大局限运行的代码尤其有意义。一种最根基的并发模式就是对一个计数器的读写。就其自己而言，现今处理惩罚这个问题有许多要领，可是没有一种能比Java 8提供的要领高效或优雅。
到今朝为止，这个问题是用原子类（Atomics）来办理的，它直接操作了CPU的“较量并互换”指令（CAS）来测试并配置计数器的值。问题在于当一条CAS指令因为竞争而失败的时候，AtomicInteger类会死等，在无限轮回中不绝实验CAS指令，直到乐成为止。在产生竞争概率很高的情况中，这种实现被证明长短常慢的。
来看Java 8的LongAdder。这一系列类为大量并行读写数值的代码提供了利便的办理步伐。利用超等简朴。只要初始化一个LongAdder工具并利用它的add()和intValue()要领来累加和采样计数器。
这和旧的Atomic类的区别在于，当CAS指令因为竞争而失败时，Adder不会一直占着CPU，而是为当前线程分派一个内部cell工具来存储计数器的增量。然后这个值和其他待处理惩罚的cell工具一起被加到intValue()的功效上。这淘汰了重复利用CAS指令或阻塞其他线程的大概性。
假如你问你本身，什么时候应该用并发加法器而不是原子类来打点计数器？简朴的谜底就是——一直这么做。
#p#副标题#e#
并行排序
正像并发加法器能加快计数一样，Java 8还实现了一种简捷的要领来加快排序。这个法门很简朴。你不再这么做：
Array.sort(myArray);
而是这么做：
Arrays.parallelSort(myArray);
这会自动把方针数组支解成几个部门，这些部门会被放到独立的CPU核上去运行，再把功效归并起来。这里独一需要留意的是，在一个大量利用多线程的情况中，好比一个忙碌的Web容器，这种要领的长处就会削弱（低落90%以上），因为越来越多的CPU上下文切换增加了开销。
切换到新的日期接口
Java 8引入了全新的date-time接口。当前接口的大大都要领都已被标志为deprecated，你就知道是时候推出新接口了。新的日期接口为Java焦点库带来了易用性和精确性，而以前只能用Joda time才气到达这样的结果（译者注：Joda time是一个第三方的日期库，比Java自带的库更友好更易于打点）。
跟任何新接口一样，好动静是接口变得更优雅更强大。但不幸的是尚有大量的代码在利用旧接口，这个短时间内不会有改变。
为了跟尾新旧接口，汗青悠久的Date类新增了toInstant()要领，用于把Date转换成新的暗示形式。当你既要享受新接口带来的长处，又要分身那些只接管旧的日期暗示形式的接口时，这个要了解显得尤其高效。
节制操纵系统历程
#p#分页标题#e#
想在你的代码里启动一个操纵系统历程，通过JNI挪用就能完成——但这个对象总令人一知半解，你很有大概获得一个意想不到的功效，而且一路陪伴着一些很糟糕的异常。
即便如此，这是无法制止的工作。但历程尚有一个讨厌的特性就是——它们搞欠好就会酿成僵尸历程。今朝从Java中运行历程带来的问题是，历程一旦启动就很难去节制它。
为了帮我们办理这个问题，Java 8在Process类中引入了三个新的要领
destroyForcibly——竣事一个历程，乐成率比以前高许多。
isAlive——查询你启动的历程是否还在世。
重载了waitFor()，你此刻可以指定期待历程竣事的时间了。历程乐成退出后这个接口会返回，超时的话也会返回，因为你有大概要手动终止它。
这里有两个关于如何利用这些新要领的好例子——
假如历程没有在规按时间内退出，终止它并继承往前走。
if (process.wait(MY_TIMEOUT, TimeUnit.MILLISECONDS)){
//乐成 }
else {
process.destroyForcibly();
}
在你的代码竣事前，确保所有的历程都已退出。僵尸历程会逐渐耗尽系统资源。
for (Process p : processes) {
if (p.isAlive()) {
p.destroyForcibly();
}
}
准确的数字运算
数字溢出会导致一些讨厌的bug，因为它本质上不会堕落。在一些系统中，整型值不断地增长（好比计数器），溢出的问题就尤为严重。在这些案例内里，产物在演进阶段运行得很好，甚至商用后的很长时间内也没问题，但最终会出奇怪的妨碍，因为运算开始溢出，发生了完全无法预料的值。
为了办理这个问题，Java 8为Math类添加了几个新的“准确型”要领，以便掩护重要的代码不受溢出的影响，它的做法是当运算高出它的精度范畴的时候，抛出一个未查抄的ArithmeticException异常。
int safeC = Math.multiplyExact(bigA, bigB); // 假如功效超出+-2^31，就会抛出ArithmeticException异常
独一欠好的处所就是你必需本身找出大概发生溢出的代码。无论如何，没有什么自动的办理方案。但我以为有这些接口总比没有好。
安详的随机数产生器
在已往几年中Java一直因为安详裂痕而饱受诟病。无论是否公道，Java已经做了大量事情来增强虚拟机和框架层，使之免受进攻。假如随机数来历于随机性不高的种子，那么那些用随机数来发生密钥可能散列敏感信息的系统就更易受进攻。
到今朝为止，随机数产生算法由开拓人员来抉择。但问题是，假如你想要的算法依赖于特定的硬件、操纵系统、虚拟机，那你就不必然能实现它。这种环境下，应用措施倾向于利用更弱的默认产生器，这就使他们袒露在更大的风险下了。
Java 8添加了一个新的要领叫SecureRandom.getInstanceStrong()，它的方针是让虚拟机为你选择一个安详的随机数产生器。假如你的代码无法完全掌控操纵系统、硬件、虚拟机（假如你的措施陈设到云可能PaaS上，这是很常见的），我发起你当真思量一下利用这个接口。
可选引用
空指针就像“踢到脚趾”一样——从你学会走路开始就陪伴着你，无论此刻你有多智慧——你照旧会犯这个错。为了辅佐办理这个老问题，Java 8引入了一个新模板叫Optional<T>。
这个模板是从Scala和Hashkell警惕来的，用于明晰声明传给函数或函数返回的引用有大概是空的。有了它，太过依赖旧文档可能看过的代码常常变换的人，就不需要去揣摩某个引用是否大概为空。
Optional<User> tryFindUser(int userID) {
或
void processUser(User user, Optional<Cart> shoppingCart) {
Optional模板有一套函数，使得采样它更利便，好比isPresent()用来查抄这个值是不长短空，可能ifPresent()你可以通报一个Lambda函数已往，假如isPresent()返回true，这个Lambda函数就会被执行。欠好的处所就跟Java 8的新日期接口一样，等这种模式逐渐风行，渗透到我们利用的库中和日常设计中，需要时间和事情量。
用新的Lambda语法打印Optional值：
value.ifPresent(System.out::print);
