当前位置: 首页 > 面试题库 >

锁定锁与非锁定锁

卜方伟
2023-03-14
问题内容

我在这里思考:如果您有2个线程执行需要同步的FAST操作,那么非阻塞方法不是比阻塞/上下文切换方法更快/更好的方法吗?

非阻塞的意思是:

while(true){如果(checkAndGetTheLock())中断;}

如果您有太多线程在锁中循环,我唯一想到的就是饥饿(CPU耗尽)。

如何平衡一种方法与另一种方法?


问题答案:

以下是 Java Concurrency in Practice 关于此主题的内容:

JVM可以通过旋转等待(反复尝试获取锁直到成功)来实现阻塞,也可以通过在操作系统中挂起阻塞的线程来实现阻塞。哪种效率更高取决于上下文切换开销与锁定可用时间之间的关系。对于短暂的等待,最好使用自旋等待;对于长时间的等待,最好使用暂停。一些JVM根据过去等待时间的分析数据在两者之间进行自适应选择,但是大多数JVM只是挂起线程等待锁定。

还有(这是IMO最重要的一点):

不要过分担心无竞争的同步的代价。基本机制已经相当快,并且JVM可以执行其他优化,从而进一步降低或消除成本。相反,将优化工作集中在实际发生锁争用的区域上。



 类似资料:
  • 我看不出有什么区别。我读到了这篇文章:actual-use-of-lockinterruptbly-for-a-reentrantlock 想测试一下。代码如下: 这里是Inturrept班 控制台输出: 正如回答中提到的“这与常规锁()相同。但如果另一个线程中断,等待的线程lockInterruptbly()将抛出InterruptedException。”即使它是锁着的。lock()或lock

  • 锁定 Subversion的拷贝-修改-合并版本控制模型的关键是其合并算法,也就是如何处理多个用户修改同时修改一个文件产生冲突时的算法。Subversion本身只提供了一个这样的算法,其三方区别算法可以足够聪明的的行粒度的数据处理,Subversion也支持使用外置比较工具(“外置 diff3”一节中有描述),有一些可以做得非常好,或许可以提供以单词或字母粒度的算法。但是,这些工具的共同点是基于文

  • 我正在编写一个应用程序来管理或自定义Android设备的解锁屏幕。它的工作原理如下: 用户使用电源按钮锁定屏幕。 用户尝试解锁屏幕,从而再次按下电源按钮 我的活动弹出--屏幕仍然锁定 用户回答问题,如果答案正确,屏幕解锁 我已经为第三步创建了一个活动,并将以下代码添加到其方法中: 这工作正常,完全符合我的期望。我的问题是第四步。我已经搜索并找到了许多解决方案,但没有一个适合我。 如何以编程方式锁定

  • 我们有一个系统,我们偶尔会得到一个乐观的锁定异常。我们在代码中已经解决了这个问题,但现在我正在查看JPA 2,并看到它有一个用于处理这个问题的注释(@版本) 我们的问题是,一个表上有多个事务,如果表锁已满,则即使未对相同的记录进行更改,也会导致乐观锁定异常。 我们在JBoss 4.2服务器上使用hibernate,数据库可以是MySQL或SQL服务器。 如果改为使用@Version,这会在两个数据

  • 我在某处读到过,在< code>ConcurrentHashmap中,整个Map对象没有被锁定,而是在Map的一部分上进行锁定。 有人能详细说明一下锁定是什么时候出现的吗? 读取地图时没有锁,而更新地图时只使用锁,这是对的吗?

  • 问题内容: 有没有一种方法可以检测MySQL中的锁定表?我的意思是表被命令锁定。 (请注意,有兴趣检测使用来获取的 命名 锁的读者应改为从get_lock显示显示所有当前锁。) 问题答案: 显示每个表的状态及其锁定。 对于命名锁,请查看显示来自get_lock的所有当前锁