b**********h
发帖数: 419 | 1 工作里用Spring 框架，把Thread都包装好了，
现在去面试的时候，multi-threading都是必问问题，
简单的synchronize还能应付得过去，
有的面试官往深里头问，notify的应用，如何debug多线程什么的，我就只懂得皮毛了
有什么好project练习多线程吗？ |
a9
发帖数: 21638 | 2 JAVA工作问多线程问题？让他去死
【在 b**********h 的大作中提到】
: 工作里用Spring 框架，把Thread都包装好了，
: 现在去面试的时候，multi-threading都是必问问题，
: 简单的synchronize还能应付得过去，
: 有的面试官往深里头问，notify的应用，如何debug多线程什么的，我就只懂得皮毛了
: 有什么好project练习多线程吗？
|
b**********h
发帖数: 419 | 3 最近面了4个，无一例外都问多线程
【在 a9 的大作中提到】
: JAVA工作问多线程问题？让他去死
|
o**n
发帖数: 2130 | 4 有锁多线程数据结构全部实现一遍
无锁多线程数据结构全部实现一遍 |
n*****3
发帖数: 1584 | 5 现在难道不是 用 scala， clojure 这些 function al
language 吗？ IM MU table is the key
【在 o**n 的大作中提到】
: 有锁多线程数据结构全部实现一遍
: 无锁多线程数据结构全部实现一遍
|
z******n
发帖数: 1183 | 6
Java 也就知道简单的synchronize
C++的貌似多点。可以用pthread，有各种lock
但是现在感觉无锁的transaction更厉害
可以用到database上
今天面了一个小公司，面试官啥都不懂。想要招backend的
我讲了半天multi threading,结果人家根本云里雾里，毫不关心
问个问题也没讲清楚。我回家了才想到原来他想问的是这个
也是醉了。。。。
【在 b**********h 的大作中提到】
: 工作里用Spring 框架，把Thread都包装好了，
: 现在去面试的时候，multi-threading都是必问问题，
: 简单的synchronize还能应付得过去，
: 有的面试官往深里头问，notify的应用，如何debug多线程什么的，我就只懂得皮毛了
: 有什么好project练习多线程吗？
|
g****u
发帖数: 252 | 7 查了一下, gcc竟然已经已经支持transactional memory好久了.
__transaction_atomic { if (a > b) b++; }
这个实际用起来还是很爽的.
https://gcc.gnu.org/wiki/TransactionalMemory
【在 z******n 的大作中提到】
:
: Java 也就知道简单的synchronize
: C++的貌似多点。可以用pthread，有各种lock
: 但是现在感觉无锁的transaction更厉害
: 可以用到database上
: 今天面了一个小公司，面试官啥都不懂。想要招backend的
: 我讲了半天multi threading,结果人家根本云里雾里，毫不关心
: 问个问题也没讲清楚。我回家了才想到原来他想问的是这个
: 也是醉了。。。。
|
w****e
发帖数: 1883 | 8 把Java concurrency in practice看两遍，你就成专家了。java多线程越用越感觉设计
的好，尤其是引入了Doug Lea 的package之后，功能强大灵活性极高。老有些语言和
library比如Scala之类的号称隐藏了多线程的细节，让你不用担心race condition，其
实都是扯淡。这样在设计上的简化必然是以牺牲灵活性功能性为代价的。我面试别人必
然会问一个基本的producer consumer问题，如果连这么简单的东西都搞不清楚的人，
脑子根本连完成日常任务的能力都不够。 |
b**********h
发帖数: 419 | 9 推荐的好书，建议具体，包子送上
【在 w****e 的大作中提到】
: 把Java concurrency in practice看两遍，你就成专家了。java多线程越用越感觉设计
: 的好，尤其是引入了Doug Lea 的package之后，功能强大灵活性极高。老有些语言和
: library比如Scala之类的号称隐藏了多线程的细节，让你不用担心race condition，其
: 实都是扯淡。这样在设计上的简化必然是以牺牲灵活性功能性为代价的。我面试别人必
: 然会问一个基本的producer consumer问题，如果连这么简单的东西都搞不清楚的人，
: 脑子根本连完成日常任务的能力都不够。
|
c*********e
发帖数: 16335 | 10 这书确实好。我看了一遍就觉得收获很多。现在看了3遍了。不過，这玩艺即使通过了
测试，在live website可能出现意想不到的问题。当然，都希望不会出现问题。
【在 w****e 的大作中提到】
: 把Java concurrency in practice看两遍，你就成专家了。java多线程越用越感觉设计
: 的好，尤其是引入了Doug Lea 的package之后，功能强大灵活性极高。老有些语言和
: library比如Scala之类的号称隐藏了多线程的细节，让你不用担心race condition，其
: 实都是扯淡。这样在设计上的简化必然是以牺牲灵活性功能性为代价的。我面试别人必
: 然会问一个基本的producer consumer问题，如果连这么简单的东西都搞不清楚的人，
: 脑子根本连完成日常任务的能力都不够。
|
|
|
w**z
发帖数: 8232 | 11 我每次一开始看，就睡着了，咋办？
【在 c*********e 的大作中提到】
: 这书确实好。我看了一遍就觉得收获很多。现在看了3遍了。不過，这玩艺即使通过了
: 测试，在live website可能出现意想不到的问题。当然，都希望不会出现问题。
|
c*********e
发帖数: 16335 | 12 头悬梁，针刺骨。
【在 w**z 的大作中提到】
: 我每次一开始看，就睡着了，咋办？
|
w**z
发帖数: 8232 | 13 年纪大了，悬不动了。
【在 c*********e 的大作中提到】
: 头悬梁，针刺骨。
|
w****e
发帖数: 1883 | 14 多线程编程是不能指望测试的，必须要从design的时候就对，对design 和
implementation非常清楚才行。如果出了bug到production phase需要找原因，那才是
nightmare。
【在 c*********e 的大作中提到】
: 这书确实好。我看了一遍就觉得收获很多。现在看了3遍了。不過，这玩艺即使通过了
: 测试，在live website可能出现意想不到的问题。当然，都希望不会出现问题。
|
w****e
发帖数: 1883 | 15 用不着就没必要看，不过看看挺有意思的。Java是个非常成熟的语言，但是也比较
boring，只有多线程的部分还算是有趣，有一些思考的余地。而且很多多线程的书开始
都是讲概念比较枯燥，你可以跳着看。
原来我一直以为多线程是每个马工都应该掌握的基本知识，但是后来发现远远不是这么
回事，很多人会用个什么Runnable, ExecutorService,但是究竟是怎么回事脑子里一团
浆糊。难怪有些语言和库把“不用考虑多线程”当成卖点，其实少了对多线程的控制就
少了一个非常强大的工具。
我曾经去面过一个startup，里面一位技术大牛（说起名字很多人都知道的那种），跟
我讨论多线程，非常斩钉截铁地说如果只有一个CPU，CPU只有一个core，那么多线程就
只对实现逻辑有帮助，对性能没有任何帮助，因为所谓多线程，在最底层的实现是分时
的。我试着问他，即使这样，那计算速度和IO的的不匹配呢? 他回答，那也没用，因为
它是分时的。
后来我发现，很多干活又快又好甚至大牛的人，似乎只是个熟练工，对于稍微需要深层
次思考一点的问题没有兴趣。
【在 w**z 的大作中提到】
: 我每次一开始看，就睡着了，咋办？
|
c*****e
发帖数: 3226 | 16 干活又快又好！= 牛人
【在 w****e 的大作中提到】
: 用不着就没必要看，不过看看挺有意思的。Java是个非常成熟的语言，但是也比较
: boring，只有多线程的部分还算是有趣，有一些思考的余地。而且很多多线程的书开始
: 都是讲概念比较枯燥，你可以跳着看。
: 原来我一直以为多线程是每个马工都应该掌握的基本知识，但是后来发现远远不是这么
: 回事，很多人会用个什么Runnable, ExecutorService,但是究竟是怎么回事脑子里一团
: 浆糊。难怪有些语言和库把“不用考虑多线程”当成卖点，其实少了对多线程的控制就
: 少了一个非常强大的工具。
: 我曾经去面过一个startup，里面一位技术大牛（说起名字很多人都知道的那种），跟
: 我讨论多线程，非常斩钉截铁地说如果只有一个CPU，CPU只有一个core，那么多线程就
: 只对实现逻辑有帮助，对性能没有任何帮助，因为所谓多线程，在最底层的实现是分时
|
t***k
发帖数: 610 | 17 不思考挺好
【在 w****e 的大作中提到】
: 用不着就没必要看，不过看看挺有意思的。Java是个非常成熟的语言，但是也比较
: boring，只有多线程的部分还算是有趣，有一些思考的余地。而且很多多线程的书开始
: 都是讲概念比较枯燥，你可以跳着看。
: 原来我一直以为多线程是每个马工都应该掌握的基本知识，但是后来发现远远不是这么
: 回事，很多人会用个什么Runnable, ExecutorService,但是究竟是怎么回事脑子里一团
: 浆糊。难怪有些语言和库把“不用考虑多线程”当成卖点，其实少了对多线程的控制就
: 少了一个非常强大的工具。
: 我曾经去面过一个startup，里面一位技术大牛（说起名字很多人都知道的那种），跟
: 我讨论多线程，非常斩钉截铁地说如果只有一个CPU，CPU只有一个core，那么多线程就
: 只对实现逻辑有帮助，对性能没有任何帮助，因为所谓多线程，在最底层的实现是分时
|
c*********e
发帖数: 16335 | 18 多线程是在cpu里分时的，所以，每次切换到另外一个thread之前，要把当前的thread
的变量值都要存起来，这个就相当费时间和资源。当然，现在i5,i7之类的有多个cpu,
会好点。one thread, async就比这个好很多。
multi-thread programming,就像当初的c++的程序员忘记释放大的object的内存就会出
事一样，成了编程的一个瓶颈。java解决了c++的“程序员忘记释放大的object的内存
”的问题，但是，java自己又增加了一个棘手的难题，这就是multi-thread
programming.
【在 w****e 的大作中提到】
: 用不着就没必要看，不过看看挺有意思的。Java是个非常成熟的语言，但是也比较
: boring，只有多线程的部分还算是有趣，有一些思考的余地。而且很多多线程的书开始
: 都是讲概念比较枯燥，你可以跳着看。
: 原来我一直以为多线程是每个马工都应该掌握的基本知识，但是后来发现远远不是这么
: 回事，很多人会用个什么Runnable, ExecutorService,但是究竟是怎么回事脑子里一团
: 浆糊。难怪有些语言和库把“不用考虑多线程”当成卖点，其实少了对多线程的控制就
: 少了一个非常强大的工具。
: 我曾经去面过一个startup，里面一位技术大牛（说起名字很多人都知道的那种），跟
: 我讨论多线程，非常斩钉截铁地说如果只有一个CPU，CPU只有一个core，那么多线程就
: 只对实现逻辑有帮助，对性能没有任何帮助，因为所谓多线程，在最底层的实现是分时
|
w****e
发帖数: 1883 | 19 多线程的context switch overhead早就可以做的非常小了。即使只有一个CPU，除非你
的程序是永远100% CPU不停地算，不然的话很多real world的application大部分时间
都花在等待慢几个数量级的IO上，这种时候多线程当然比单线程效率高多了。
至于C++的多线程就别拿出来说了，简直是尼玛反人类。用了几年pthread, 突然用上了
Java thread,有一种指哪儿打哪儿的感觉，想怎么操纵怎么操作。棘手的难题？看不出
来。我觉得Java最大的贡献之一就是多线程编程在保留了易用性的同时还提供了强大的
功能性。当然，这一切要归功天才的Doug Lea.
thread
【在 c*********e 的大作中提到】
: 多线程是在cpu里分时的，所以，每次切换到另外一个thread之前，要把当前的thread
: 的变量值都要存起来，这个就相当费时间和资源。当然，现在i5,i7之类的有多个cpu,
: 会好点。one thread, async就比这个好很多。
: multi-thread programming,就像当初的c++的程序员忘记释放大的object的内存就会出
: 事一样，成了编程的一个瓶颈。java解决了c++的“程序员忘记释放大的object的内存
: ”的问题，但是，java自己又增加了一个棘手的难题，这就是multi-thread
: programming.
|
c*********e
发帖数: 16335 | 20 java让连内存都忘记释放的人能够编程，代价就是速度变慢。
【在 w****e 的大作中提到】
: 多线程的context switch overhead早就可以做的非常小了。即使只有一个CPU，除非你
: 的程序是永远100% CPU不停地算，不然的话很多real world的application大部分时间
: 都花在等待慢几个数量级的IO上，这种时候多线程当然比单线程效率高多了。
: 至于C++的多线程就别拿出来说了，简直是尼玛反人类。用了几年pthread, 突然用上了
: Java thread,有一种指哪儿打哪儿的感觉，想怎么操纵怎么操作。棘手的难题？看不出
: 来。我觉得Java最大的贡献之一就是多线程编程在保留了易用性的同时还提供了强大的
: 功能性。当然，这一切要归功天才的Doug Lea.
:
: thread
|
|
|
w****e
发帖数: 1883 | 21 速度变慢是相对的，该用C++的地方用Java当然不合适，但是很多server side的程序那
点速度差根本就不是瓶颈，不过我看你说来说去也说不到点上都是些人云亦云的东西，
估计你自己也糊里糊涂。
【在 c*********e 的大作中提到】
: java让连内存都忘记释放的人能够编程，代价就是速度变慢。
|
c*********e
发帖数: 16335 | 22 当年在学校的时候，教c++的老师就很鄙视java.人云亦云也有错？你说啥是瓶颈？
【在 w****e 的大作中提到】
: 速度变慢是相对的，该用C++的地方用Java当然不合适，但是很多server side的程序那
: 点速度差根本就不是瓶颈，不过我看你说来说去也说不到点上都是些人云亦云的东西，
: 估计你自己也糊里糊涂。
|
w***g
发帖数: 5958 | 23 pthread是很傻x. 不过C++11以后C++线程已经满血复活了, 不会比java差.
我这里有一个简单源程序攻略 (以前贴过), 总结了
C++11里线程相关的主要特性.
程序里主要是中文注释, 浏览器看可能有乱码. 需要下下来用编辑器看.
http://www.wdong.org/thread-tutorial.cpp
可以运行, g++编译用
g++ -pthread -std=c++11 thread-tutorial.cpp
C++是用来写算法的, 不适合实现业务逻辑.
【在 w****e 的大作中提到】
: 多线程的context switch overhead早就可以做的非常小了。即使只有一个CPU，除非你
: 的程序是永远100% CPU不停地算，不然的话很多real world的application大部分时间
: 都花在等待慢几个数量级的IO上，这种时候多线程当然比单线程效率高多了。
: 至于C++的多线程就别拿出来说了，简直是尼玛反人类。用了几年pthread, 突然用上了
: Java thread,有一种指哪儿打哪儿的感觉，想怎么操纵怎么操作。棘手的难题？看不出
: 来。我觉得Java最大的贡献之一就是多线程编程在保留了易用性的同时还提供了强大的
: 功能性。当然，这一切要归功天才的Doug Lea.
:
: thread
|
w****e
发帖数: 1883 | 24
我擦，你上学的时候一个老师的观点也称论据了？你自己没有独立思考？没有自己的观
点？server side啥是瓶颈是common sense, 如果你还需要问/反问，只能说你太嫩。
【在 c*********e 的大作中提到】
: 当年在学校的时候，教c++的老师就很鄙视java.人云亦云也有错？你说啥是瓶颈？
|
c*********e
发帖数: 16335 | 25 你知道，你就说啊。和和
【在 w****e 的大作中提到】
:
: 我擦，你上学的时候一个老师的观点也称论据了？你自己没有独立思考？没有自己的观
: 点？server side啥是瓶颈是common sense, 如果你还需要问/反问，只能说你太嫩。
|
h*******n
发帖数: 82 | 26 简单了解就学学mutex锁，同步之类老生常谈的东西，估计几天就搞定了。
进一步就上无锁，建议用C++11，推荐preshing.com， 明白什么是无锁编程，内核锁，
用户锁，自旋锁，操作系统调度，自旋策略，然后看看别人怎么写无锁的数据结构，尤
其掌握LMAX Disruptor，这个玩意号称是java的人搞的，但是我怎么觉得dpdk，linux
内核好多年前就有了。 |
s******d
发帖数: 278 | 27 读了您的笔记。
// 思考：如果=之前A已经和某线程关联了怎么办？
在C++ Concurrency in Practice Chapter 2.3 Transferring ownership of a thread
, 好像可以通过std::move操作
void some_function();
void some_other_function();
std::thread t1(some_function);
std::thread t2=std::move(t1);
t1=std::thread(some_other_function);
std::thread t3;
t3=std::move(t2);
t1=std::move(t3);
【在 w***g 的大作中提到】
: pthread是很傻x. 不过C++11以后C++线程已经满血复活了, 不会比java差.
: 我这里有一个简单源程序攻略 (以前贴过), 总结了
: C++11里线程相关的主要特性.
: 程序里主要是中文注释, 浏览器看可能有乱码. 需要下下来用编辑器看.
: http://www.wdong.org/thread-tutorial.cpp
: 可以运行, g++编译用
: g++ -pthread -std=c++11 thread-tutorial.cpp
: C++是用来写算法的, 不适合实现业务逻辑.
|
s******d
发帖数: 278 | 28 不知道现在业界主流是无锁还是有锁啊，好奇哈哈
linux
【在 h*******n 的大作中提到】
: 简单了解就学学mutex锁，同步之类老生常谈的东西，估计几天就搞定了。
: 进一步就上无锁，建议用C++11，推荐preshing.com， 明白什么是无锁编程，内核锁，
: 用户锁，自旋锁，操作系统调度，自旋策略，然后看看别人怎么写无锁的数据结构，尤
: 其掌握LMAX Disruptor，这个玩意号称是java的人搞的，但是我怎么觉得dpdk，linux
: 内核好多年前就有了。
|
b***i
发帖数: 3043 | 29 我也是刚看了这个帖子学会notify。不过挺简单的。
【在 b**********h 的大作中提到】
: 工作里用Spring 框架，把Thread都包装好了，
: 现在去面试的时候，multi-threading都是必问问题，
: 简单的synchronize还能应付得过去，
: 有的面试官往深里头问，notify的应用，如何debug多线程什么的，我就只懂得皮毛了
: 有什么好project练习多线程吗？
|
b*******s
发帖数: 5216 | 30 lock free isn't necessarily faster
【在 s******d 的大作中提到】
: 不知道现在业界主流是无锁还是有锁啊，好奇哈哈
:
: linux
|
|
|
g*********e
发帖数: 14401 | 31 有些performance critical 的东西，数据都在内存里，io wait 没多少，这个时候还
是要做到较少context switch, 用taskset之类把process stick到core上
【在 w****e 的大作中提到】
: 多线程的context switch overhead早就可以做的非常小了。即使只有一个CPU，除非你
: 的程序是永远100% CPU不停地算，不然的话很多real world的application大部分时间
: 都花在等待慢几个数量级的IO上，这种时候多线程当然比单线程效率高多了。
: 至于C++的多线程就别拿出来说了，简直是尼玛反人类。用了几年pthread, 突然用上了
: Java thread,有一种指哪儿打哪儿的感觉，想怎么操纵怎么操作。棘手的难题？看不出
: 来。我觉得Java最大的贡献之一就是多线程编程在保留了易用性的同时还提供了强大的
: 功能性。当然，这一切要归功天才的Doug Lea.
:
: thread
|
g*********e
发帖数: 14401 | 32 Gc个100毫秒，前端说不定就哭爹喊娘了
【在 w****e 的大作中提到】
: 速度变慢是相对的，该用C++的地方用Java当然不合适，但是很多server side的程序那
: 点速度差根本就不是瓶颈，不过我看你说来说去也说不到点上都是些人云亦云的东西，
: 估计你自己也糊里糊涂。
|
w***g
发帖数: 5958 | 33 也不能这么说. 那么多python的还在混呢.
java看python的感觉估计跟C++看java的差不多.
【在 g*********e 的大作中提到】
: Gc个100毫秒，前端说不定就哭爹喊娘了
|
n*******0
发帖数: 2002 | 34 Java 开发比 C++ 要快很多，这个都没有疑问的。
Java的运行时速度在绝大多数情况下跟C++没差多少（C2 编译之后）。
运行速度这个东西，只要不是数量级的差距，只需堆硬件就可以了。
开发速度这个东西，就不是简单的堆程序员能够解决的。
Java目前的主要问题是在对实时性有要求的场景下，怎么把GC的暂停搞下去。
【在 c*********e 的大作中提到】
: 当年在学校的时候，教c++的老师就很鄙视java.人云亦云也有错？你说啥是瓶颈？
|
w**z
发帖数: 8232 | 35 如果前端对很小很小一部分的request 有 100ms 的 延迟都不接受的话，后端确实不能
用 Java, 但 web application , who cares, 网络延迟经常远大于 100ms.
【在 g*********e 的大作中提到】
: Gc个100毫秒，前端说不定就哭爹喊娘了
|
g****t
发帖数: 31659 | 36 CPU的simulator好多是C++写的。
和C类语言结合作速度优化相对容易。
堆硬件客户不接受。
例如现在手机那么轻薄，堆一个砖头恐怕不行。
【在 n*******0 的大作中提到】
: Java 开发比 C++ 要快很多，这个都没有疑问的。
: Java的运行时速度在绝大多数情况下跟C++没差多少（C2 编译之后）。
: 运行速度这个东西，只要不是数量级的差距，只需堆硬件就可以了。
: 开发速度这个东西，就不是简单的堆程序员能够解决的。
: Java目前的主要问题是在对实时性有要求的场景下，怎么把GC的暂停搞下去。
|
