百科问答小站 logo
百科问答小站 font logo



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

  

user avatar   rednaxelafx 网友的相关建议: 
      

嗯。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感兴趣:

A bit of sugar for j.u.c.locks with try-with-resources?

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

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




  

相关话题

  为什么很多程序员不用 switch,而是大量的 if...else if ...? 
  项目代码的公共部分该由谁去维护? 
  Java 集合类库的顶层里的 Collection,List,Set 是抽象类的话是否更“正确”一些? 
  a += a *= a; 为什么在C++和Java算出了不同结果? 
  为什么安装不了java?这是啥问题? 
  PHP 比 Java 的开发效率高在哪? 
  注解参数为什么不支持Object? 
  i2c为什么会有TR和TF上升沿和下降沿时间最小时间限制? 
  随着互联网的崛起,还有必要学习 C++ 吗?貌似 C++ 越来越难找工作了... 
  不同编程语言的程序员之间有鄙视链么? 

前一个讨论
有哪些游戏是体现人性本恶的?
下一个讨论
软件开源后,能否有开源和商业化两种授权?





© 2025-04-16 - tinynew.org. All Rights Reserved.
© 2025-04-16 - tinynew.org. 保留所有权利