本帖最后由 Neverbelazy 于 2013-5-19 11:03 编辑
看多线程的时候, 思考了一个关于为什么多线程会降低运行效率的问题, 欢迎大家讨论!
同步的使用是否会改变CPU的执行权? 如果同步不能干预到CPU, 那么是否可以认为对一个同步代码操作的线程越多,执行效率越低？
17:32 5/17更新
-------------------------------------- 个人的理解 ------------------------------------
1. CPU分配执行权, JVM虚拟机只能一定程度地干预 Java线程间的协作
2. 同步的原理是上锁, 上锁的目的是为了其他线程运行到此段代码处 无法继续运行, 但是CPU还是可以给其他线程分配运行权
3. 所以 假设3个线程，运行到同步代码块时, 一个先进去了,另外两个进不去, 但是CPU执行权还是在3个线程中分配, 假设CPU平均分配这就相当于一段时间内只有1/3的时间是有效运行,其它时段都在判断锁, 上锁,进不去。
4. 所以这样试想一下, 如果有n个线程, 那么有效的运行效率就只是 1/n.
那么, 有会引出一个问题, CPU可能分配的最小单步执行是什么？ 如何提高同步时代码运行效率？ 毕老师买票的程序是否可以被改进而使运行效率提高？
5/19日更新（没有新回复, 最近又有了些思考，重新编辑在此处作为感言）
----------------------------------------下面的参考,作为感言 --------------------------------------
1. CPU最小执行不是一条语句, 因为一条语句往往也是多步执行, 比如System.out.println(x.getName()+" "+x.getAddress()); 更比如 i++; 也是两步执行, CPU的最小执行是原子操作(细节暂时太了解)
2. 基于 上面提到的, 买票的例子出现数据错乱是在最后的一次买票（如果不巧此时所有窗口线程同事挂起,则最后出现负数票）,一种提高效率的方法是在买票程序中加一个flag, flag监测 比如剩10张票了(10>窗口数,), 此时再进入有同步的代码块，这样就节省了同步的次数（懒汉单例设计模式为提高效率,最后在同步代码块外加的一步判断不也是这样吗）
3. 其实，仔细想下，线程冻结的机制也是可以节省同步时CPU运行效率的，因为冻结了的线程就不参与CPU执行权的分配了
|
|
收藏
淘帖
踩
