归档之于 ‘ 2013 年8 月

讨喜的隔离可变性(二)角色的特性

声明:本文是《Java虚拟机并发编程》的第五章,感谢华章出版社授权并发编程网站发布此文,禁止以任何形式转载此文。

角色是一种能够接收消息、处理请求以及发送响应的自由运行的活动(activity),主要被设计用来支持异步化且高效的消息传递机制。

每个角色都有一个内建的消息队列,该队列与手机上所使用的短信队列十分相似。假设Sally和Sean同时给Bob的手机发了短信,则运营商将会把这两条短信都保存起来以便Bob在方便的时候取走。类似地,基于角色的并发库允许多个角色并发地发送消息。默认情况下,消息发送者都是非阻塞的;它们会先把消息发送出去,然后再继续处理自己的业务逻辑。类库一般会让特定的角色顺序地拾取并处理消息队列中消息,只有将当前消息处理完或将消息委派给其他角色并发处理之后,这个角色才能够接收下一个消息。

阅读全文

讨喜的隔离可变性(一)用角色实现隔离可变性

声明:本文是《Java虚拟机并发编程》的第五章,感谢华章出版社授权并发编程网站发布此文,禁止以任何形式转载此文。

Java将OOP变成了可变性驱动(mutability-driven)的开发模式[1],而函数式编程则着重强调不可变性,而这两种极端的方式其实都是有问题的。如果每样事物都是可变的,那么我们就需要妥善处理可见性和竞争条件。而在一个真实的应用程序中,也并非所有事物都是不可变的。即使是纯函数式语言也提供了代码限制区,在该区域内允许出现带副作用的逻辑以及按顺序执行这些逻辑的方法。但无论我们倾向于哪种编程模型,避免共享可变性都是毋庸置疑的。

共享可变性——并发问题的根源所在——是指多个线程可以同时更改相同的变量。而隔离可变性——一个可以消除大部分并发问题的不错的折衷方案——是指任意时刻有且只有一个线程(或角色)可以访问某个可变变量。 阅读全文

讨喜的隔离可变性-前言

声明:本文是《Java虚拟机并发编程》的第五章,感谢华章出版社授权并发编程网站发布此文,禁止以任何形式转载此文。

曾有个的医嘱是这样说的:“如果它伤到了你,那就别再用它了”。在并发编程领域,共享可变性就是那个“它”。

虽然JDK的线程API使我们可以非常容易地创建线程,但如何防止线程冲突和逻辑混乱却又成了大问题。STM虽然可以解决部分问题,但是在一些类似Java这样的语言中,我们仍不得不非常小心谨慎地避免非托管可变变量和事务逻辑中产生某些副作用。而令人惊讶的是,当共享可变性消失的时候,所有那些令人纠结的问题也都随之消失了。 阅读全文

return top