标签: livelock

有人可以解释一下(代码)的例子,死锁和活锁之间的区别是什么？

我理解livelock是什么,但我想知道是否有人有一个很好的基于代码的例子呢？以代码为基础,我并不是说"两个人试图在走廊里相互过去".如果我再读一遍,我会失去午餐.

当您使用Session-Per-Request模式时,您在使用NHibernate的3层应用程序中使用哪种模式/体系结构需要支持事务失败的重试？(因为ISession在异常后变为无效,即使这是死锁或超时或活锁异常).

当我偶然发现一些我不理解的行为时,我试图使用Java同步"原语"(synchronized,wait(),notify())来实现类似于Java的有界BlockingQueue接口.

我创建了一个能够存储1个元素的队列,创建两个等待从队列中获取值的线程,启动它们,然后尝试将两个值放入主线程中的同步块中的队列中.它大部分时间都可以工作,但有时候等待值的两个线程似乎开始相互唤醒并且不让主线程进入同步块.

这是我的(简化)代码:

import java.util.LinkedList;
import java.util.Queue;

public class LivelockDemo {
    private static final int MANY_RUNS = 10000;

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < MANY_RUNS; i++) { // to increase the probability
            final MyBoundedBlockingQueue ctr = new MyBoundedBlockingQueue(1);

            Thread t1 = createObserver(ctr, i + ":1");
            Thread t2 = createObserver(ctr, i + ":2");

            t1.start();
            t2.start();

            System.out.println(i + ":0 ready to enter synchronized block");
            synchronized (ctr) {
                System.out.println(i + …

进程 A 和 B 都在 Redis 资源 R 上运行。

这些进程可以并行执行，我需要两个进程在更改 R 值时确定 R 的值。

因此，我将Redis 事务与WATCH 命令一起使用。来自文档：“只有在没有其他客户端修改任何 WATCHed 键的情况下，我们才要求 Redis 执行事务。否则根本不输入事务。”

要在失败的情况下重试，建议的方法是循环 Watch/Multi-exec 循环，直到成功为止。但是，我担心 A 和 B 可能会无限期地开始循环（即：活锁）。

这有什么值得担心的吗？更好的是，该怎么办？在重试时设置随机超时会解决问题吗？