本文主要是介绍Akka 并发编程简述，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
概述
Akka官方网址：https://akka.io/
Akka是一个构建在JVM上，基于Actor模型的的并发框架，为构建伸缩性强，有弹性的响应式并发应用提高更好的平台
Akka解决了什么问题？
传统的处理并发思路是多线程处理，为了保证数据一致性和正确性，最通常的方法就是使用锁。通过加锁可以保证同一时刻只有一个线程能进入该方法，但这是一个代价非常昂贵的方法：
这些现实存在的问题让我们只能两者选一：
另外，锁只能在本地更好的利用，当我们的程序部署在不同的机器上时，我们只能选择使用分布式锁，但不幸的是，分布式锁的效率可能比本地锁低好几个量级，对后续的扩展也会有很大的限制，分布式锁的协议要求多台机器在网络上进行相互通信，因此延迟可能会变得非常高。
Actor模型
Akka的核心就是Actor，所以不得不说Actor。
Actor模型可以这样理解：
假定现实中的两个人，他们只知道对方的地址，他们想要交流，给对方传递信息，但是又没有手机，电话，网络之类的其他途径，所以他们之间只能用信件传递消息，很像现实中的的邮政系统，你要寄一封信，只需根据地址把信投寄到相应的信箱中，具体它是如何帮你处理送达的，你就不需要了解了，你也有可能收到收信人的回复，这相当于消息反馈。上述例子中的信件就相当于Actor中的消息，Actor与Actor之间只能通过消息通信。
Actors模型的特点：
Actor模型概图：
从上图中我们可以看到，Actor与Actor之前只能用消息进行通信，当某一个Actor给另外一个Actor发消息，消息是有顺序的，你只需要将消息投寄的相应的邮箱，至于对方Actor怎么处理你的消息你并不知道，当然你也可等待它的回复。
其实只从上面一些描述来看，并不能看出Actor在处理并发问题上的有什么优势。
但实际上，它的优势在于两点：简化并发编程，提升程序性能
1.简化并发编程：
我们一开始说过并发导致最大的问题就是对共享数据的操作，我们在面对并发问题时多采用的是
用锁去保证共享数据的一致性，但这同样也会带来其他相关问题，比如要去考虑锁的粒度（对方法，程序块等），锁的形式（读锁，写锁等）等问题，这些问题对并发程序来说是至关重要的，但一个初写并发程序的程序员来说，往往不能掌控的很好，这无疑给程序员在编程上提高了复杂性，而且还不容易掌控，但使用Actor就不导致这些问题，首先Actor的消息特性就决定了了在与Actor通信上不会有共享数据的困扰，另外在Actor内部是串行处理消息的，同样不会对Actor内的数据造成污染，用Actor编写并发程序无疑大大降低了编码的复杂度。
2.提升程序性能：
我们之前说过既然用单线程处理，那如何保证程序的性能？首先Actor是非常轻量级的，你可以在程序中创建许多个Actor，而且Actor是异步的，那么如何利用它的这个特性呢，我们要做的就是把相应的并发事件尽可能的分割成一个个小的事件，让每个Actor去处理相应的小事件,充分去利用它异步的特点，来提升程序的性能。
所以，Actor模型因为不会再任何地方使用锁，所以发送者不会被阻塞，成千上万个Actor可以被合理的分配在几十个线程上执行，充分利用了现代CPU的潜力。
Scala中原生的Actor并不能完成很多事，不是一套完整的并发解决方案，不适合用于生产环境，比如错误恢复，状态持久化等，所以在较新版本的Scala类库中，Akka包已经取代了原生的Actor。
- Actor中的消息是不可变的
- Actor是串行处理消息的
- 对并发模型进行了更高的抽象
- 异步、非阻塞、高性能的事件驱动编程模型
- 轻量级事件处理（1GB内存可容纳百万级别个Actor）
- 每个Actor都有对应一个邮箱
- 不使用锁，但会导致状态混乱。
- 使用大量的锁，但是会降低性能并很容易导致死锁。
- 锁非常严重的限制并发，它在现在的CPU架构上代价是非常大的，它需要操作系统暂停和重启线程。
- 调用者的线程会被阻塞，以致于它不能去做其他有意义的任务，举个例子我们希望桌面程序在后台运行的时候，操作UI界面也能得到响应。在后台，线程阻塞完全是浪费的，有人可能会说可以通过启动新线程进行补偿，但线程也是一种非常昂贵的资源。
- 使用锁会导致一个新的问题：死锁。
这篇关于Akka 并发编程简述的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
