Java的synchronize机制

java天生丽质, 在诸多方面都有惊世骇俗的创举, 她不仅把面向对象的思想发挥得淋漓尽致, 同时在诸多系统级别的问题解决方案上别出心裁. 这里暂且记下多年来对synchronized机制不断深入感悟的心得, 在后面的设计中惟参.

随着多线程技术的诞生和广泛流传, 线程间同步的问题随之而来. 在线程技术问世之前, 除了面向PC的单进程的DOS, 各种领路的大中小型计算机操作系统早就有了多进程的概念, 而且也发展了自己的进程间通信技术(IPC), 通过IPC在进程间共享资源时, 同样存在同步问题, 这与多线程间的同步是非常类似的, 唯一的差别是多线程共享同一个地址空间, 而多进程分别处在不同的地址空间当中, 只有通过IPC的调用才能把某一块共享内容映射到相同的地址上去. 因为这样的历史因素, 很自然的, 用于多进程间同步的IPC功能, 被稍加修改以后, 甚至原封不动的用来解决线程间的同步问题, 线程同步很容易的找到了它经典,成熟,经历过考验的解决方案. 但是java没有在这个问题上亦步就趋, java的设计者真是个完美主义者, 他想到了更优美的实现方式, 并且SUN给了他实现这个想法的机会. 这个方式就是现在被广泛应用的synchronized关键字. 当然这也是由于有了java本土的多线程支持这个培养基才使得她成为可能, 如果是用于进程间同步, 也很难做到如此优美.

不要小看一个简简单单的关键字, synchronized 省却了POSIX/SYSV IPC中繁复的系统互斥量加锁/解锁调用, WIN32为这个问题发明了临界区, 但那也仅仅从IPC前进了一小步而已. 而且, java作为一个平台, 在虚拟机规范层面上定义了加锁/解锁的操作指令, 但是在java作为程序设计语音的层面上, 她真正的美化,简化了同步机制的表达方式, 而且在使用更简单的同时, 避免了一个绝对比例的互斥资源编程误区和陷阱,  这是一种不言之妙, 连java语音规范本身在提及这个特性时也只是一板一眼的讲述了她的用法和特性, 没有一句的虚夸. 但是这个应用到一个方法体或者一个代码块的关键字, 从根本上消灭了其他程序设计语音中可能的锁定对象但不去及时解锁的错误逻辑, 而这种逻辑在一个判断条件比较复杂的算法里是极容易发生的, 一个程序员在编程时把它作为一个anti-pattern时刻放在脑袋里预警要消耗掉不小的脑力资源, 而正是像这样种种的预警消耗, 降低了C/C++程序员的开发效率, 增加了代码的bug率, 从而拖长了软件的开发维护周期, 降低了软件的可靠性.