一个java内存刷新volatile:一个好的程序设计? [英] one java memoryFlushing volatile: A good programdesign?

查看:73
本文介绍了一个java内存刷新volatile:一个好的程序设计?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

与此相关的一个问题: java:正在使用在一个变量处相对于每个变量处都是挥发性的

its a related question to this one: java: using volatile at one variable VS each variable

我有一个或多个不同的对象。我想更改其中的某些状态,然后使该状态对其他线程可见。

i have one or more different objects. i want to change some state in it and then i want to make that state visible to other threads.

出于性能原因,我不想使该对象中的每个成员变量易挥发的。
有时我想在单线程应用程序中使用这些对象。因此,在那种情况下,挥发物也将是有害的。

For performance reasons i dont want to make each member variable in that objects volatile. And sometimes i want to use these objects in a single thread application. So in that case the volatile would be also bad.

所以我有以下内容:

//these following mehtods change some internal variable state. These variables are not volatile or synchronized

boolean volatile memoryFlusher=false;

Thread1:

obj1->changeSomeState();
obj1->changeMoreState();
obj2->alsoSomeStateChange();

//and now i want to make that state visible to others

memoryFlusher=false; //volatile write


Thread2:

boolean tmp=memoryFlusher; // volatile read but variable is not used again

obj1->getState();
obj2->getState();

所以到现在为止,它与我一开始就链接的相关问题大致相同。

So till now its more or less the same to my related question i linked at the beginning.

所以现在我想问以下问题:

So now i want to ask the following:

我的memoryFlusher没有被优化吗? (在我的另一个问题中没有得到解答)
每个易失性写/读操作都会刷新ALL的所有memoryState?其他变量(还是非挥发性变量)?

My memoryFlusher is not optimzed away? (unanswerd in my other question) Each volatile write/read flushes all memoryState of ALL? other (also none-volatile-)variables?

现在真正的新问题是:

是好的设计,我在那里吗?
因为我没有在任何地方看到这样的代码,所以我在这里发布了。

is that a good design, i do there? Cause i didnt saw any code anywhere like this, i posted here.

我应该以其他方式编程我的Progamm吗?
还有其他最佳实践可以提高性能并提高可视性吗?
在程序设计视图中还有其他最佳实践,是否没有这样做?

Should i program my Progamm in a other way? Is there a other best practise to increase the performance and getting visibilty? Is there other best practise in the program-design view, not having doing something like this?

编辑:

我所更改的状态未释放。
所以我想要一个可变的内存刷新器,并且没有锁定机制。它应该将许多单个volatile变量替换为1。某个地方我不需要显式的易失性内存刷新原因我使用了同步的,例如

the state i change is unreleated. So i want with that memory-variable one memoryflusher, and no lock mechanism. It should replace a lot of single volatile variable to one. somewhere i dont need that explicit volatile memoryFlushing cause i use a synchronized, for example

synchronized(x)
{
    ...
    obj1->stateChange() //if internally is used a volatile, then i have a volatile memory flush and later the synchronized-end memory-flush, i guess (is that right?)
    ...
}

可能有用吗?!

摘要:
但这是正确的吗,我认为使用那个memoryFlushing吗?

summary: But is that correct, in that way i think using that memoryFlushing?

推荐答案


我的memoryFlusher没有被优化吗?

My memoryFlusher is not optimzed away?

不,不会对 memoryFlusher 的读写操作进行优化

No, the write to and read from memoryFlusher will not be optimized away.


每个易失性写/读操作都会刷新所有内存的状态

Each volatile write/read flushes all memoryState of ALL

是的,它将内存同步到两个线程。但是,仅当您可以检测到从一个线程到另一个线程的更改时,它才有效。

Yes, it will synchronize memory to both threads. However, it only works if you can detect the change from one thread to another.

在您的示例中,您阅读了 memoryFlusher ,但阅读了 memoryFlusher 在初始化时为 false 。您怎么知道 Thread-1 实际上是写给它的?如果线程1在此行 obj1-> changeMoreState ,并且线程2读取 memoryFlusher 。这两个值都将是 false ,因此您不知道线程1是否真正完成。由于未确定发生的顺序,因此您不同步。

In your example, you read memoryFlusher, but memoryFlusher is false on initialization. How do you know Thread-1 actually wrote to it? What if, Thread-1 is at this line obj1 -> changeMoreState, and Thread-2 reads memoryFlusher. Both values would be false here and so you don't know if Thread-1 actually completed.You are out of sync as you haven't established your happens-before ordering.

要更正代码,应在 memoryFlusher true 仅当 memoryFlusher 为true时,$ c>字段和Thread-2才应继续。这有效地建立了您的顺序,但同时也使您的代码更加混乱。

To correct your code, you should write true to the memoryFlusher field and Thread-2 should only continue if memoryFlusher is true. This effectively establishes your ordering, but it also makes your code more confusing.

我建议使用 StampedLock 而不是尝试这样做。当不经常进行写操作时,StampedLock可为您提供真正的快速读取。

I'd suggest using a StampedLock instead of trying this. The StampedLock gives you really fast reads when writes are not going to be frequent.

这篇关于一个java内存刷新volatile:一个好的程序设计?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆