线程池之外：Java并发并不像您想象的那么糟糕
Apache Hadoop，Apache Spark，Akka，Java 8流和Quasar： 针对Java开发人员的经典用例以及最新的并发方法
关于并发性更新概念的讨论很多，但是许多开发人员还没有机会将他们的想法缠住。 在本文中，我们将介绍您需要了解的有关Java 8流，Hadoop，Apache Spark，Quasar光纤和Reactive编程方法的知识，并帮助您保持循环，尤其是当您不使用它们时。定期地 这不是未来，这正在发生。
我们在这里处理什么？
在谈论并发时，表征当前问题的一种好方法是回答一些问题，以更好地理解它：
- 它是数据处理任务吗？ 如果是这样，是否可以将其分解为独立的工作？
- 操作系统，JVM和您的代码之间有什么关系？ （本地线程与轻量级线程）
- 涉及多少台机器和处理器？ （单核与多核）
让我们仔细研究每种方法，找出每种方法的最佳用例。
1.从线程池到并行流
单台机器上的数据处理，让Java负责线程处理
在Java 8中，我们已经引入了新的Stream API，该API允许对数据流应用聚合操作，例如Filter，Sort或Map。 当应用.parallelStream（）时，流还允许在多核计算机上进行并行操作-使用Java 7中引入的Fork / Join框架在线程之间拆分工作。这是Java 6 java.util.concurrency库的改进，我们在其中遇到了ExecutorService，用于创建和处理我们的工作线程池。
Fork / Join也建立在ExecuterService之上，与传统线程池的主要区别在于它们如何在线程之间分配工作，从而实现多核机器支持。 使用简单的ExecuterService，您可以完全控制工作线程之间的工作负载分配，确定线程要处理的每个任务的大小。 另一方面，在使用Fork / Join的情况下，有一种工作窃取算法可以抽象化线程之间的工作负载处理。 简而言之，这允许将大型任务划分为较小的任务（分叉），并在不同的线程中进行处理，最终合并结果–平衡线程之间的工作。 但是，这不是灵丹妙药。
有时并行流甚至可能使您放慢速度，因此您需要仔细考虑。 添加.parallelStream（）到你的方法可能会导致瓶颈和怠工（约15％的速度较慢这一基准，我们跑），精线经过的线程数。 假设我们已经在运行多个线程，并且在其中一些线程中使用了.parallelStream（），从而向池中添加了越来越多的线程。 这很容易变成我们的核心无法处理的事情，并且由于增加了上下文切换而减慢了一切。
底线：并行流以在内核之间分配工作负载的方式抽象处理单台计算机上的线程。 但是，如果您想有效地使用它们，那么请务必牢记硬件，不要产生超出计算机处理能力的更多线程。
2. Apache Hadoop和Apache Spark
重型起重：多台机器上的大数据处理
移至多台机器，数PB的数据和类似于从推特或重型机器学习算法中提取所有提及Java的推文的任务。 在谈到Hadoop时，必须采取进一步措施并考虑更广泛的框架及其组件，这一点很重要：Hadoop分布式文件系统（HDFS），资源管理平台（YARN），数据处理模块（MapReduce）以及其他库和实用程序Hadoop（通用）所需。 在这些工具之上还有其他可选工具，例如在HDFS（HBase）之上运行的数据库，查询语言（Pig）的平台以及数据仓库基础结构（Hive）等。
这就是Apache Spark作为新的数据处理模块的地方，它以其内存内性能和快速执行的弹性分布式数据集（RDD）的使用而闻名，这与不使用内存内（和内存中）的Hadoop MapReduce不同。磁盘）操作。 Databricks发布的最新基准测试表明，在对PB级数据进行排序时，Spark比Hadoop 快3倍 ，而节点使用量却减少了10倍 。
Hadoop的经典用例是查询数据，而Spark以其快速的机器学习算法运行时间而闻名。 但这只是冰山一角，正如Databricks所说： “ Spark使Hadoop集群中的应用程序在内存中的运行速度提高了100倍，甚至在磁盘上运行时也提高了10倍” 。
底线： Spark是Hadoop生态系统中的新后起之秀。 有一个普遍的误解，就是我们谈论的是无关或竞争的事物，但是我相信我们在这里看到的是框架的演变。
3.类星体纤维
将本地线程中断为虚拟轻量级线程
我们有机会在Hadoop中运行，现在让我们回到单机上。 实际上，让我们比标准多线程Java应用程序进一步放大，并专注于一个单线程。 就我们而言，HotSpot JVM线程与本机OS线程相同，仅保留一个线程并在其中运行“虚拟”线程就可以了。 Java没有本机光纤支持，但不用担心， Parallel Universe的Quasar吸引了我们。
Quasar是一个开放源代码的JVM库，它支持光纤（也称为轻量级线程），并且还充当Actor框架，我将在后面提到。 上下文切换是这里的游戏名称。 由于我们受到内核数量的限制，因此当本机线程数增加时，我们将面临越来越多的上下文切换开销。 解决这一问题的一种方法是使用支持“多线程”的单线程的光纤。 看起来像是threadcepiton的情况。
光纤也可以看作是线程池的演进，它规避了并行流所带来的线程过载的危险。 它们使扩展线程变得更容易，并允许大量并发的“轻”线程。 它们无意替换线程，而应用于相对频繁阻塞的代码，就像它们充当了真正的异步线程一样。
底线： Parallel Universe正在Java中提供一种新的并发方法，尚未达到v1.0，但绝对值得一试。
4.演员和反应式编程
使用Java处理并发的其他模型
在“ 反应式宣言”中 ，以4条原则描述了新机芯：响应，弹性，弹性和消息驱动。 这基本上意味着快速，容错，可扩展且支持无阻塞通信。
让我们看看Akka演员如何支持这一点。 为简化起见，将Actor视为具有某种状态和某种行为的人，通过交换发送到彼此邮箱的消息进行交流。 应该为每个应用程序创建一个Actor系统，该系统具有将任务分解为较小任务的层次结构，以便每个Actor最多只有一个监督Actor。 演员可以执行任务，通过委托其他演员进一步分解事件，或者在失败的情况下，将其上报给主管。 无论哪种方式，消息都不应包含行为或共享可变状态，每个Actor都具有独立的声明和自身的行为。
与大多数开发人员习惯的并发模型相比，这是一种范式转变。 这与我们在这里讨论的前3个主题的发展有些偏离。 尽管它的起源可以追溯到70年代，但直到最近几年它才受到关注，并得到了复兴，以更好地适应现代应用程序的需求。 Parallel Universe的Quasar还基于轻量级线程支持Actor。 实施方面的主要区别在于纤维/轻质纱线。
底线：采用Actor模型可以轻松管理线程池，将其留给工具箱。 兴趣的复兴来自当今应用程序要处理的问题，即高度并发的系统，我们可以使用更多的内核。
结论
我们已经通过4种方法使用并发或并行算法来解决问题，并且采用了最有趣的方法来应对当今的挑战。 希望这有助于激起您的兴趣，并更好地了解当今并发的热门话题。 超越线程池的趋势是，负责任地将其委派给该语言及其工具–将开发资源集中在提供新功能上，而不是花费大量时间解决竞争条件和锁定问题。