并发已不再是语言层面上的事情了

原文链接  译者：张军 校对：方腾飞

本文将并发和内存管理做了个类比。最近有一个说法是因为现代工程师几乎总是面对计算机集群编程，所以我们需要用于构建分布式系统的工具。这就意味着我们需要在语言层面支持分布式系统开发。像GO和Erlang这样的语言其优势正好符合这个观点。

GO和Erlang可能最终会流行，但我不认为是这个原因。分布式系统开发并不会成为每个应用开发者日常工作的一部分，因为那将会是件非常痛苦的事情。在某种程度上，我想今天发生的事情是因为缺乏良好的分布式计算框架，而迫使应用去重新实现一些分布式系统原语。但这种情况不会一直存在，而必将有一些框架提供不同的编程模型，在弹性机器池上处理分布和并发问题。

MapReduce已经解决了这个问题。MapReduce编程几乎都是单线程的，并发是由框架来管理，另外有助于你写好MapReduce程序的原因是，有很多用户级别(user-level)的并发原语，并且MapReduce是高度并行的。

这不是个新事物，即使是Java servlets，其所有的缺陷主要是因为抽象了线程模型，但是至少对于应用程序来说只需要通过阻塞I/O与一个数据库进行交互。

我觉得有三大基本领域需要处理：在线，近实时和离线。

在线领域，我们创建请求/响应式服务，并行性是通过将每个请求的处理当作一个工作单元，划分到不同的线程和机器。我见过该模型的多个变种，从“服务查询语言”到将REST调用拼接在一起的DSLs，它们的共同点就是抽象并发的处理，而不需要像线程一样直接访问单个服务器的并发机制。 在近实时处理领域，流处理框架做的很好，通过异步处理而根本不用考虑并发。而且你关心的并发和并行只在框架层面，你写的代码看起来完全是单线程的。 离线领域似乎为了不同的目标朝着YARN框架 （校对注：YARN框架介绍）的方向发展。

几乎所有这些框架的共同点是它们都不需要用户直接管理并发。

我认为这些高层次的领域（在线，异步和离线）将被证明会长期存在，但是我不认为我们需要十几个基础分布式计算框架来涵盖这些领域。

这让我花了很多时间来思考，在语言层面支持单机并发（软件事务内存和其他）效果是有限的。它只会帮助框架的实现者而不是最终用户。相比应用开发者，框架实现者会有一些非常不同的需求，他们更关心性能和细粒度的控制。尽管这显然是一个有争议的说法，我不确定线程和锁对框架开发者来说是否是一个可行的模型，毕竟，对于一个受训过的团队它们做的非常好，并有出色的性能和控制能力。 

成为高级程序员不得不了解的并发 到目前为止，你学到的都是顺序编程，顺序编程的概念就是某一时刻只有一个任务在执行，顺序编程固然能够解决很多问题，但是对于某种任务，如果能够并发的执行程序中重要的部分就显得尤为重要，同时也可以极大提高程序运行效率，享受并发为你带来的便利。但是，熟练掌握并发编程理论和技术，对于只会CRUD的你来说是一种和你刚学面向对象一样的一种飞跃。
并发编程从操作系统底层工作整体认识开始 在多线程、多处理器、分布式环境的编程时代，并发是一个不可回避的问题。既然并发问题摆在面前一个到无法回避的坎，倒不如拥抱它，把它搞清楚，花一定的时间从操作系统底层原理到Java的基础编程再到分布式环境等几个方面深入探索并发问题。先就从原理开始吧。 计算机系统层次结构 早期计算机系统的层次 最早的计算机用机器语言编程，机器语言称为第一代程序设计语言
【高并发】信不信？以面向对象的思想是可以写好高并发程序的！ 最近，有小伙伴留言，现在大部分开发都是面向对象开发，那如何以面向对象的方式写好并发程序呢？那好，今天我们就来聊聊这个话题。
再说J.U.C之并发基础工具 [TOC] 上一讲我们讲述了线程池整个的过程，这一讲我们来先底层的3个组件，synchronized,Unsafe以及LockSupport ## Unsafe ### 常用api * 获取对象指定Field对应的内存地址偏移量，可以理解为跟C++中的指针一样，获取到了属性的地址，在一个对象中 * 属性的偏移地址是固定的，不会发生变化
ali清英 方腾飞，花名清英，英文名kiral，并发编程网创始人，支付宝技术专家，《Java并发编程的艺术》作者。