C#与JAVA二者是对标下的产物,无论设计思想还是语法格式都非常相似,相恨相杀一路走来各自拥有一群拥趸,思想理念都传承自面向对象的C++,不过要说血缘关系还是C#更近一些,保留了比较多的C++的影子让人多了几分熟悉的味道,IDE上VS也比MyEclipse用户体验好很多,不用idea去比明显偏心眼VS,好吧你说对了。
C#和C++都提供了良好完备的线程间同步机制,C#保留了更多的C++烙印,JAVA则干练的多让开发者省心不少。过去在面向过程的编程思路上,锁的操作基本都是基于语句的,锁的范围从加锁开始到解锁终止,代码编写的过程中各种小心锁区间的逻辑处理,一个异常就可能导致万劫不复的死锁。C#和JAVA把更多面向底层的锁操作封装起来,通过赋予对象实例一个修饰词的方法,极大的简化了步骤,当然也可以对语句块加锁,省略了显式的繁琐操作。
C# | JAVA | C++ | |
获取 | Monitor.Enter(object); Monitor.TryEnter(object); |
||
休眠 | Monitor.Wait(object); | final void wait(); | pthread_cond_wait(_cond, _mutex); pthread_cond_timewait(_cond, _mutex, _abstime); |
唤醒 | Monitor.Pulse(object); Monitor.PulseAll(object); |
final void notify(); final void notifyAll(); |
pthread_cond_signal(_cond); pthread_cond_broadcast (_cond); |
释放 | Monitor.Exit(object); |
上表显示了C#和JAVA语言基于监视器的同步方法的函数,C#比JAVA多了对监视器的获取和释放操作,二者都提供休眠等待时间,唤醒操作都提供单播和多播两种方式,在明确被唤醒对象且预知其执行方法及结果的前提下建议单播方式唤醒,否则多播唤醒后再逐个投入睡眠导致的惊群上下文切换会造成比较大的系统开销。需要特别注意的地方是按照甲骨文的推荐把wait()方法放到一个循环中可以有效避免假唤醒(spurious wakeup)情况的发生,虽然Oralce强调这种情况发生的概率极小,其实意思是说:我可告诉你,不听是你的事情,出了问题别找我。表中用C++做陪衬说明是为了更好的比较这种机制的适用场景,那就是并不是简单的粗暴加锁解锁,而是有条件有尺度的以最小开销获取独占操作。
前几天出门体验了一次7号共享电单车,以为无桩的可以为所欲为骑行,结果冲了押金又充值,扫码开锁竟然要指定目的地,因为目的地周边没有停车场,只好骑到地铁站再换乘,这叫啥事呀,账上趴着充值剩余的金额,提不出来也不知道下次啥时候消费,有种上当受骗的感觉,有桩的共享出行交通工具都是反人类设计,改改吧。