agileJava

来源: BlogBus 原始链接: http://www.blogbus.com:80/blogbus/blog/diary.php?diaryid=257196 存档链接: https://web.archive.org/web/20040904172414id_/http://www.blogbus.com:80/blogbus/blog/diary.php?diaryid=257196

agileJava agilejava,天天都要进步:) <<<又迟到了 | 首页 | 一个很好的介绍IoC的文章>>> 多线程一定会运行得更快吗？时间: 2004-07-08 有关线程的使用，一直有各种各样的说法，今天又找到了一个： http://www.javalobby.org/thread.jspa?forumID=61&threadID=13077 In dealing with some other developers, I have realized that there seems to be some misconception about running multiple threads and their impact on performance. Making tasks ( or jobs ) all run in separate threads does not mean your program will run any faster. "To increase the performance of running X number of jobs, I will run all of the them at once by running each job in a separate thread," I heard a colleague say. But how will this help? You cannot make the processor run any faster by running multiple threads. The CPU can only run 1 task at a time. Instead of decreasing the time it takes to run X number of jobs, you are basically just making all the jobs finish at approximately the same time. But the required time to complete all of the jobs has not changed. To demonstrate this, I have a simple test case in which you can compare how long it takes to run X number of jobs in a single threaded manner versus a multi-threaded manner, i.e. submit each job one at a time or all of them at once. Included in the zip file are 3 source files, an Ant build file, and a jar file. The program was compiled with version 1.4.2_03. In this test case, the definition of a Job is to just multiply 2 random doubles 10,000,000 times. Pretty useless I know, but this is just a test. To run the program, do the following:

Type "ant run" from the command line ( assuming you're using Ant ).
Type in a number of jobs in the edit field, say 25, and press the run button.
The jobs will be executed one at a time until they all finish.
Note the time it takes to complete all jobs.
Now select the "Run multi-threaded" checkbox and press the run button again. Now all jobs are being executed at the same time ( almost ). Remember that the CPU can really only run a single task at a time.
Note that the time difference is insignificant. Here were my average results running on a P3 550MHz single CPU machine: Number of jobs 25 50 75 Single thread 3.00 6.12 8.90 Multi thread 2.97 5.83 8.92 (Time is in minutes) As you can see the time difference is insignificant. Of course, on a multi processor machine, the story is a little different. In this environment, you can have multiple threads running at the exact same time. But even here, you don't really see a significant benefit -at least in this sample- until you submit 200 jobs or more. And even then, the difference is only about 30 seconds. With this in mind one must evaluate carefully whether or not multi-threading is really needed even on a multi CPU machine. There are reasons to use multiple threads in an application; however, increasing performance as in this scenario is not one of them. The CPU can only run so fast, regardless of how many threads there are. So, it is my humble opinion that additional threads should not be introduced into an application unless it is absolutely necessary. It simply makes the program more complex and introduces other problems, such as synchronization and deadlocks, without adding any significant benefits. agilejava 发表于 2004-07-08 17:34 引用(Trackback0) 评论谢谢好文章，我对线程的了解很少。要找个时间好好的恶补一下了 snail ( ) 发表于 2004-07-22 10:06 good point on deadlock. I am doing some trouble shooting on a DB2, WAS V5 based deadlock problem. Thanks for DB2 event monitor to capture the deadlock. It is from 2 java threads resulting in lock conflict on 2 DB2 tables.. very classic deadlock problem. Now i start to understand what 've learned at school. agilejava回复Victor说：多线程有时真的会把人搞晕，昨天查一个bug，一直以为是哪里的同步没有做好，一遍遍的运行，等待错误重现，到最近才发现是jdk1.4的一个bug,下载了jdk1.5 beta2，昨天运行了一晚，今天又是一天，我刚从家里来看看程序有没有问题，一切正常，现在我一提多线程就心跳，一方面同步加多了影响效率，另一方面多会影响稳定性，真是难以取舍：) (2004-07-25 19:12) Victor ( jython.blogbus.com ) 发表于 2004-07-24 03:02 yup,yup... we have these deadlocks problems. After working like dogs for over 1 week, I found one of the EJB finder does a "select for update" instead of "select". This puts a X lock on one of the deadlocked table. damn... you know there is 1 guy here helped me to see the generated code of EJB.. we see "select.. for update" in the code.. that 's why.. After fixed this, we still have other type of deadlocks happening, i am kinda exhausted working 10 hrs every day tracing the thead output, DB2 event monitor, run all kinds of test, yun! Victor ( jython.blogbus.com ) 发表于 2004-07-30 02:52 发表评论最后更新 jdk1.5初体验 jdk1.5的新功能 JDK1.5的jvmti 好久没有写blog了 Spring Framework 1.1 RC1 spring初试胜之不武，悲哀足球 sun.java2d.noddraw=true 极限编程结束了好用的myEclipse