标签: thread-synchronization

下面是Thread进入同步块的代码,等待5秒然后退出.我已经Thread同时启动了两个实例.

期望是其中一个线程将拥有对同步对象的锁定,而另一个将等待.5秒后,当锁拥有者退出时,等待线程将执行.

但是,实际上,两个线程同时执行同步块并同时退出.

预期产出:

Thread-X <timeX> received the lock.
Thread-X <timeX+5s> exiting...
Thread-Y <timeY> received the lock.
Thread-Y <timeY+5s> exiting...

实际产量:

Thread-X <time> received the lock.
Thread-Y <time> received the lock.
Thread-X <time+5s> exiting...
Thread-Y <time+5s> exiting...

我在这里错过了什么吗？

import java.text.SimpleDateFormat;
import java.util.Date;

public class Test2 {
public static void main(String[] args) {
    MyRunnable m = new MyRunnable();
    Thread t = new Thread(m);
    Thread t1 = new Thread(m);
    t.start();
    t1.start();
    }
}

class MyRunnable implements Runnable { …

如果我们在具有两个处理器的机器上有两个正在运行的线程，并且Thread.yield()在其中一个线程中调用，那么是否有理由不做任何事情（调度程序实际上会忽略请求），因为我们有足够的处理器来服务正在运行的线程？

我想澄清一下,在关系与volatile变量一起工作之前会发生什么.我们有以下变量:

public static int i, iDst, vDst;
public static volatile int v;

和线程A:

i = 1;
v = 2;

和线程B:

vDst = v;
iDst = i;

以下语句是否符合Java内存模型(JMM)？如果没有,那么正确的解释是什么？

• i = 1总是发生在以前 v = 2
• v = 2 发生 vDst = v在JMM 之前,只有它实际发生在时间之前
• i = 1 发生 iDst = i在JMM 之前(并且iDst可以预测分配1)如果v = 2实际发生vDst = v在时间之前
• 否则,在i = 1和之间的顺序iDst …

private volatile static Singleton uniqueInstance

在单独使用双锁方法进行同步时,为什么单个实例声明为volatile？我可以在不将其声明为volatile的情况下实现相同的功能吗？

我正在阅读Peter B. Galvin的"操作系统概念中的关键部分问题".根据它

1)进度是:如果没有进程在其关键部分执行,并且某些进程希望进入其关键部分,那么只有那些未在其余部分中执行的进程才能参与决定哪个进程将在下一个进入其关键部分,选择不能无限期推迟.

和

2)有界等待是:在进程请求进入其关键部分之后且在该请求被授予之前,允许其他进程进入其关键部分的次数存在约束或限制.

我不理解作者想要在两种情况下说什么.

您能否通过提供与此定义相关的适当示例来让我理解.

谢谢.

我的问题与此问题非常类似:@Async阻止线程继续,直到其他线程完成

基本上我需要在更多线程中运行〜数百次计算.我想只运行一些并行线程,例如5个线程,其中5个计算是并行的.

我使用spring框架和@Async选项是很自然的选择.我不需要全功能的JMS队列,这对我来说有点开销.

有任何想法吗 ？谢谢

我正在学习java多线程,我发现很难理解synchronized块的工作原理:

 synchronized(Object o){
     // do something
    }

请给出一些示例代码,可以显示对象o被阻止.根据我的理解,在同步块被执行时,将阻止从另一个线程访问对象o？

有人可以向我解释多线程中上述操作的工作和差异吗？

让我们假设我们必须同步对共享资源的读/写访问.多个线程将在读取和写入时访问该资源(大多数时间用于读取,有时用于写入).让我们假设每次写入总是触发读操作(对象是可观察的).

对于这个例子,我会想象一个这样的类(原谅语法和风格,它仅用于说明目的):

class Container {
    public ObservableCollection<Operand> Operands;
    public ObservableCollection<Result> Results;
}

我很想将a ReadWriterLockSlim用于此目的而且我把它放在Container水平上(想象对象不那么简单,一个读/写操作可能涉及多个对象):

public ReadWriterLockSlim Lock;

的实施Operand和Result对这个例子没有意义.现在让我们想象一些观察Operands并将产生结果的代码Results:

void AddNewOperand(Operand operand) {
    try {
        _container.Lock.EnterWriteLock();
        _container.Operands.Add(operand);
    }
    finally {
        _container.ExitReadLock();
    }
}

我们的hypotetical观察者会做类似的事情,但是要使用一个新元素,它将锁定EnterReadLock()以获取操作数然后EnterWriteLock()添加结果(让我省略代码).这会因为递归而产生异常但是如果我设置LockRecursionPolicy.SupportsRecursion那么我只是打开我的代码到死锁(来自MSDN):

默认情况下,使用LockRecursionPolicy.NoRecursion标志创建ReaderWriterLockSlim的新实例,并且不允许递归.建议对所有新开发使用此默认策略,因为递归会引入不必要的复杂性并使您的代码更容易出现死锁.

为清楚起见,我重复相关部分:

递归[...]使您的代码更容易出现死锁.

如果我没有错,LockRecursionPolicy.SupportsRecursion如果来自同一个线程,我问一个,比方说,读取锁定,然后其他人要求写入锁定然后我将有一个死锁然后MSDN说的是有道理的.此外,递归也会以可测量的方式降低性能(如果我使用的话,它不是我想要的,ReadWriterLockSlim而不是ReadWriterLock或者Monitor).

问题(S)

最后我的问题是(请注意我不是在寻找关于通用同步机制的讨论,我知道这个生成器/ observable/observer场景有什么问题):

• 在这种情况下有什么好处？为了避免ReadWriterLockSlim赞成Monitor(即使在现实世界中,代码读取将远远超过写入)？ …

我对Java同步有疑问.我想知道我的类中是否有三个Synchronized方法,并且一个线程在一个synchronized方法中获取锁定,其他两个将被锁定？我问这个问题,因为我对以下陈述感到困惑.

当一个线程在一个对象的synchronized方法中时,所有其他希望执行这个synchronized方法或该对象的任何其他同步方法的线程都必须等待.此限制不适用于已具有锁定并正在执行对象的同步方法的线程.这种方法可以调用对象的其他同步方法而不会被阻塞.当然,任何线程都可以随时调用对象的非同步方法