多线程:所有线程执行到一个地方才往下执行,怎么实现
展开全部
主线程抛出一个子线程异步处理一些东西,这时主线程要等待子线程运行完成再完成(其实我是为了统计运行时间的)。
这里抛出的子线程可能递归的调用自己,就是再抛一个他的子线程出来,但是到底一共抛多少,事先是不知道的。
应用场景:1)多线程扫描文件夹内的文件,遇到文件夹内有子文件夹,要递归调用扫描线程的,等到全部扫描完成后,返回结果,显示;
2)多线程快速排序,第一次肯定是单线程的,第一次排序完成后,会分两半,这两半多线程排,递归调用了这个排序线程,这两半很有可能,极大有可能再各分两半,也就是会有4个子线程的子线程再排序。
我试过网上的那个 CountDownLatch ,但是他只能实现定义好子线程的数量,但是在以上两种情景下,事先你是不知道会有多少个子线程的!
PS:在某种需求中,比如一个大型的任务,常常需要分配好多子任务去执行,只有当所有子任务都执行完成时候,才能执行主任务,这时候,就可以选择CyclicBarrier了。这个貌似也要在开始的时候设定总线程数:CyclicBarrier(int parties)
这个和countDownLatch就差不多了呢!
你觉得呢 问题补充:niuzai 写道亲,CyclicBarrier可能是你想要的。
PS:在某种需求中,比如一个大型的任务,常常需要分配好多子任务去执行,只有当所有子任务都执行完成时候,才能执行主任务,这时候,就可以选择CyclicBarrier了。我再来看看~~试试看! 问题补充:niuzai 写道亲,CyclicBarrier这个东东是可以动态重置个数的,而countDownLatch是一次性的。只不过大多数例子CyclicBarrier初始化了个数罢了,实质上它是可以动态改变的~ 嗯 我试了下,多线程快排,小数据量还好,顺利执行了,但是数多了后,会建N多线程等待,会outofmemory,呵呵!
不过证明这个方法是可以的! 问题补充:niuzai 写道亲,那你就结合线程池操作,设置线程数目上限。不要每个任务就产生一个线程咯~ 产生新的线程是很耗内存的,线程太多当然就内存溢出咯~嗯 你说的很对!要结合线程池的!
这里抛出的子线程可能递归的调用自己,就是再抛一个他的子线程出来,但是到底一共抛多少,事先是不知道的。
应用场景:1)多线程扫描文件夹内的文件,遇到文件夹内有子文件夹,要递归调用扫描线程的,等到全部扫描完成后,返回结果,显示;
2)多线程快速排序,第一次肯定是单线程的,第一次排序完成后,会分两半,这两半多线程排,递归调用了这个排序线程,这两半很有可能,极大有可能再各分两半,也就是会有4个子线程的子线程再排序。
我试过网上的那个 CountDownLatch ,但是他只能实现定义好子线程的数量,但是在以上两种情景下,事先你是不知道会有多少个子线程的!
PS:在某种需求中,比如一个大型的任务,常常需要分配好多子任务去执行,只有当所有子任务都执行完成时候,才能执行主任务,这时候,就可以选择CyclicBarrier了。这个貌似也要在开始的时候设定总线程数:CyclicBarrier(int parties)
这个和countDownLatch就差不多了呢!
你觉得呢 问题补充:niuzai 写道亲,CyclicBarrier可能是你想要的。
PS:在某种需求中,比如一个大型的任务,常常需要分配好多子任务去执行,只有当所有子任务都执行完成时候,才能执行主任务,这时候,就可以选择CyclicBarrier了。我再来看看~~试试看! 问题补充:niuzai 写道亲,CyclicBarrier这个东东是可以动态重置个数的,而countDownLatch是一次性的。只不过大多数例子CyclicBarrier初始化了个数罢了,实质上它是可以动态改变的~ 嗯 我试了下,多线程快排,小数据量还好,顺利执行了,但是数多了后,会建N多线程等待,会outofmemory,呵呵!
不过证明这个方法是可以的! 问题补充:niuzai 写道亲,那你就结合线程池操作,设置线程数目上限。不要每个任务就产生一个线程咯~ 产生新的线程是很耗内存的,线程太多当然就内存溢出咯~嗯 你说的很对!要结合线程池的!
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询