内存锁与内存事务

内存锁是语言的失败。

DBMS使用事务封装了锁。内存事务却在微软那里不了了之。原因竟然是没有发现对它的杀手级应用。

什么是杀手级应用？

现在的语言中，几乎全部都存在着各式不同的封锁元素。包括语言级的与库级的。特别是那些所谓面向对象的语言。原因一方面是面向对象的程序中存在大量的数据共享，另一方面则是现代计算机的快速发展导致的多线程并发模式的大量应用（或者说“普及”）。

在JDon中发现几篇文章说数据库已死。我完全同意这种观点。但是我们不能让数据库就这么死去，因为它发展了那么多年，有很多值得借鉴的东西很值得保存下来或者说特性移植。面向对象的系统在内存中没错，但在内存中的对象与位于数据库中的对象并没有本质的区别，它们都是数据。所以在DBMS中对数据进行管理的一整套东西其实都可以照原样搬过来。

微软之所以没在内存事务中发现杀手级应用，很可能是因为他们自己的程序很多都是面向过程的，这样的话当然很难发现杀手级应用了。

事务的价值在于它从输出的角度对锁机制进行了封装，避免了在应用开发中很难处理或管理的死锁，粒度控制等东西。因为这些东西直接影响运行时，本来就是应该被从，至少从用户代码的层次拿掉的。用户怎么能直接“指挥”运行时呢？用户对运行时的直接“干预”，很多时候是造成系统崩溃的原因。内存指针就是一个例子。不过值得庆幸的是，它已经在JAVA中拿掉（为什么不在当时一起拿掉同步呢？有困难吗？）。

关于并发控制，我认为程序员的唯一职责应该是“定义事务”，不是更多。任何更多的职责都违背了程序语义学的观点：语言是为我服务的。而关于并发则只有“事务”才是在这种服务协议中应该出现的东西。

回到现实。

对应四种ACID问题：更新失败，脏读，不可重复读，幻影读，有四种事务隔离级别：Read uncommitted, Read committed, Repeatable Read, Serializable。四种隔离级别分别采用四种封锁（协议）实现：X锁，X锁+单次S锁，X锁+事务级S锁，范围锁。

锁有更复杂的实现如更新锁，意向锁，乐观锁，悲观锁，轻量级锁，偏向锁，自旋锁等等，都是针对不同的需求特征或事务等级定制的锁。事实上，这里面的很多只是使用了锁的名字，所以其实并不是锁，因为它们没有起到排它的作用如自旋锁，轻量级锁，偏向锁等等其实都不是锁。特别是乐观锁，却是通过不锁来达到锁的效果。

另一方面，根据被封锁的对象的大小，又可以被分为行锁，表锁，页锁，或其它范围锁，特别是对于内存数据，根据内存数据的结构与层次，锁的种类其实无限多。但是在真正的开发工作中只要找到合适粒度的对象就可以了，不必过于较真。

对应于以数据库为中心的系统和以内存为中心的系统，锁又可以分为内存锁与数据库锁。数据库锁在大部分时候并不会被程序员直接使用因为上面包了一层事务。而在以内存为中心的系统中，java 1.5以后就提供了很多的封锁类与原子操作可以被利用。特别是在1.6以后的锁优化，基本上排除了在发现真正的冲突以前的封锁开销。这些锁机制与API，加上原来就存在的语言级元素如synchronized和volatile，是采用真正的面向对象编程时必不可少的一部分。

这意味着如果要在项目中启用OO的范式进行系统开发，则对程序员的要求其实非常高。因为对上面所述这些锁机制的深刻理解，不是一个初入者可以很容易搞明白的东西。大部分的程序员都必须在碰了很多钉子以后才可能真正学会一些东西。

这里当然也有语言级的问题。如一些程序语义派的研究者的认为那样，语言的元素应该指代的是语言的执行结果，而不是运行时特性。将语言元素指向运行时特性产生很多问题，第一就是造成程序对运行时的依赖，因为程序显然依赖于语言的具体语义。事实上，程序的语义承载能力即来自于语言的语义承载能力。俗语水能载舟亦能覆舟是一样的道理。另一个问题则是程序语义的丢失。将一个语言元素的语义指向运行时的后果是，它没有被指向“运行后”的结果。在运行时中给语法元素赋值（即赋予语法元素一定的语义）是一种推脱责任的行为。这就好象指着未完工的产品对客户说：这就是你要的东西！

我其实认为程序员的知识重点是应该摆在建模上面。但是世界并不完美，我们却要工作。这就要求我们不得不拥有一些应付这个不完美世界的能力。换一句话，如果世界已经是完美的，为什么我们还需要工作呢？我们还要继续努力，因为世界还不完美（这个有点象悖论，，，因为它看上去好象是我们工作的目的是为了让世界更完美，但是事实却是世界从没有变得“更”完美或永远也不可能完美。。。归根结底，我们并不是世界。我们也不存在。真正存在的从头到尾只不过是一些雄激素而已。我们以为我们存在，只不过雄激素让我们以为我们存在然后我们便可以成为我们）。

http://www.jdon.com/oo.html, uml