Java的同步机制比起pthread方式有何优点？ 第1页

嗯。Java在语言层面上设计的同步机制是个大败笔。没啥优点可言。C#不幸掉进同一坑里了，叹气。

失败主要是在于：

• 让所有Object都可以当作锁用，增加了JVM高性能实现的复杂度。毕竟Java系统里绝大部分对象从创建到死亡都不会被当作锁来用，让每个对象都要保留空间去存储潜在的被锁的信息是个很大的浪费。所以高性能的JVM实现都会想各种办法去让对象只在需要的时候才开辟空间去存储锁的信息。这么一来原始的败笔设计虽然不影响性能，但让JVM的实现变得复杂。
• 正确的设计还是应该有专门的锁类型，只让这些对象可以被当作锁来使用，那么普通对象自然就不需要管锁不锁的事情。
• 语法层面上的synchronized语句简单归简单，但功能不够灵活，无法表达出Mutex / Lock、Condition等的完整功能。其实在有了Java 7的try-with-resources语句之后，可以很直观地在库里设计出跟synchronized一样好用的锁类型。

对比语言层面的synchronized语句：

       synchronized (obj) {   // ... }     

跟假如说使用了try-with-resources语句的锁设计：

       try (mylock.lock()) {   // ... } // auto-unlock at the end with an implied finally clause     

是不是差不多一样好用？

所以在Java 5引入java.util.concurrent.locks的库层面上的锁之后，很多人都会选择使用这个而不是用synchronized语句来实现自己需要的同步功能。可惜java.util.concurrent.locks包下的锁没有更新为使用try-with-resources功能，所以用的时候还是得自己 lock.lock(); try { ... } finally { lock.unlock(); }。

（刚发了封邮件去问OpenJDK的core-libs-dev看有没有人对try-with-resoures版API感兴趣：

等回复看看大佬们怎么说。）

考虑Java设计之初的时间背景：当时在语言层面提供完善的多线程支持的语言还没多少，Java算是探索了一种可能的设计，原本是想通过语法支持来方便多线程编程，而后来它的各种弊端才展现出来。