多线程 - 更快的方式? [英] Multi-threading -- a faster way?

查看:73
本文介绍了多线程 - 更快的方式?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在一个字段上有一个getter getInt()和一个setter setInt()的类,比较字段

I have a class with a getter getInt() and a setter setInt() on a certain field, say field

Integer Int; 

类的对象,比如 SomeClass

setInt()此处已同步 - getInt()不是。

The setInt() here is synchronized-- getInt() isn't.

我正在多个线程中更新 Int 的值。
每个线程获得值 Int ,并进行适当设置。
线程不以任何方式共享任何其他资源。

I am updating the value of Int from within multiple threads. Each thread is getting the value Int, and setting it appropriately. The threads aren't sharing any other resources in any way.

每个线程中执行的代码如下所示。

The code executed in each thread is as follows.

public void update(SomeClass c) {

        while (<condition-1>) // the conditions here and the calculation of 
                                   // k below dont have anything to do 
                                   // with the members of c
            if (<condition-2>) {
                // calculate k here 
                synchronized (c) {                        
                        c.setInt(c.getInt()+k); 
                    //    System.out.println("in "+this.toString());
                }
            }  
}   

run()方法只是在构造函数中通过传递给它的参数更新成员上面的方法:

The run() method is just invoking the above method on the members updated from within the constructor by the params passed to it:

public void run() { update(c); } 

当我在大型序列上运行时,线程不会交错 - 我看到一个线程执行很长时间没有任何其他线程运行。

When I run this on large sequences, the threads aren't interleaving much-- i see one thread executing for long without any other thread running in between.

必须有更好的方法。

我无法更改 SomeClass 的内部,或者调用线程的类的内部。

I can't change the internals of SomeClass, or of the class invoking the threads.

如何做得更好?

TIA。

// ================================= ====

//=====================================

编辑:

我不是在操纵线程的执行顺序之后。他们都有同样的优先权。它只是我在结果中看到的是暗示线程没有均匀地共享执行时间 - 其中一个,一旦接管,执行。但是,我不明白为什么这段代码应该这样做。

I'm not after manipulating the execution sequence of the threads. They all have the same priority. It`s just that what i see in the outcome is suggesting that the threads aren't sharing the execution time evenly-- one of them, once takes over, executing on. However, I can't see why this code should be doing this.

推荐答案


这就是我在结果中看到的是暗示线程不是' t均匀分享执行时间

It`s just that what i see in the outcome is suggesting that the threads aren't sharing the execution time evenly

嗯,如果您追求效率,这正是您不想要的。从一个线程执行并调度另一个线程通常非常昂贵。因此,一旦接管,执行,其中一个实际上是有利的。当然,当这种情况过度时,您可以看到更高的吞吐量,但响应时间更长。理论上。实际上,JVM的线程调度几乎适用于所有目的,并且您不希望在几乎所有情况下都尝试更改它。根据经验,如果您对毫秒级的响应时间感兴趣,您可能希望远离它。

Well, this is exactly what you don't want if you are after efficiency. Yanking a thread from being executed and scheduling another thread is generally very costly. Therefore it's actually advantageous to do one of them, once takes over, executing on. Of course, when this is overdone you could see higher throughput but longer response time. In theory. In practice, JVMs thread scheduling is well tuned for almost all purposes, and you don't want to try changing it in almost all situations. As a rule of thumb, if you are interested in response times in millisecond order, you probably want to stay away messing with it.

tl; dr:效率不高,你可能想保持原样。

tl;dr: It's not being inefficient, you probably want to leave it as it is.

编辑:

话虽如此,使用 AtomicInteger 可能对性能有帮助,并且在我看来比使用锁( synchronized 关键字)更不容易出错。你需要非常努力地击中那个变量才能获得可衡量的好处。


Having said that, using an AtomicInteger may help in performance, and is in my opinion less error prone than using a lock (synchronized keyword). You need to be hitting that variable really very hard in order to get a measurable benefit though.

这篇关于多线程 - 更快的方式?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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