线程池设置，下载线程数是怎么设置的

本文目录一览

• 1，下载线程数是怎么设置的
• 2，java线程池ExecutorService里面有多少空余线程怎么看
• 3，如何设置超线程
• 4，主线程等待子线程运行结束再完成的效果如何实现
• 5，如何合理地估算线程池大小

1，下载线程数是怎么设置的

建议使用迅雷或超级旋风进行下载，选择“配置”,然后选择左边的“任务默认属性”，在“原始地址下载线程数”中设置最大线程数即可

多线程技术的一种表现形式，也应用到了下载工具中。
你可以自己定义线程数量的。

{0}

成都创新互联长期为上1000+客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为宝山企业提供专业的网站制作、网站设计，宝山网站改版等技术服务。拥有10多年丰富建站经验和众多成功案例,为您定制开发。

2，java线程池ExecutorService里面有多少空余线程怎么看

ThreadPoolExecutor pool = (ThreadPoolExecutor) Executors.newFixedThreadPool(100);//创建线程池,这种线程池固定了线程数量pool.getActiveCount();//获取活动的线程数量100-活动数量就是空闲数量

你可以另外创建一个全局单例的对象，用来保存每个线程的获取状态

{1}

3，如何设置超线程

超线程：采用另一个思路去提高CPU的性能，让CPU可以同时执行多重线程，就能够让CPU发挥更大效率。设置超线程方法：在BIOS的CPU子项中找到 "Hyper-Threading" 这个项目, 然后ENABLE, 应该超线程就打开, (而DISABLE关闭)，重新进入系统后, 查看任务管理器, 应该会出现两个CPU窗口, 就说明超线程已经正常打开。

建议您使用 Microsoft

在bios的cpu子项中找到 "hyper-threading" 这个项目, 然后enable, 应该超线程就打开, (而disable关闭)重新进入系统后, 查看任务管理器, 应该会出现两个cpu窗口, 就说明超线程已经正常打开, 如图

{2}

4，主线程等待子线程运行结束再完成的效果如何实现

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

5，如何合理地估算线程池大小

最简单的可以利用java.util.concurrent.Executors 调用Executors.newCachedThreadPool()获取缓冲式线程池 Executors.newFixedThreadPool(int nThreads)获取固定大小的线程池

只要您遵循几条简单的准则，线程池可以成为构建服务器应用程序的极其有效的方法：不要对那些同步等待其它任务结果的任务排队。这可能会导致上面所描述的那种形式的死锁，在那种死锁中，所有线程都被一些任务所占用，这些任务依次等待排队任务的结果，而这些任务又无法执行，因为所有的线程都很忙。在为时间可能很长的操作使用合用的线程时要小心。如果程序必须等待诸如 i/o 完成这样的某个资源，那么请指定最长的等待时间，以及随后是失效还是将任务重新排队以便稍后执行。这样做保证了：通过将某个线程释放给某个可能成功完成的任务，从而将最终取得某些进展。理解任务要有效地调整线程池大小，您需要理解正在排队的任务以及它们正在做什么。它们是 cpu 限制的（cpu-bound）吗？它们是 i/o 限制的（i/o-bound）吗？您的答案将影响您如何调整应用程序。如果您有不同的任务类，这些类有着截然不同的特征，那么为不同任务类设置多个工作队列可能会有意义，这样可以相应地调整每个池。调整池的大小调整线程池的大小基本上就是避免两类错误：线程太少或线程太多。幸运的是，对于大多数应用程序来说，太多和太少之间的余地相当宽。请回忆：在应用程序中使用线程有两个主要优点，尽管在等待诸如 i/o 的慢操作，但允许继续进行处理，并且可以利用多处理器。在运行于具有 n 个处理器机器上的计算限制的应用程序中，在线程数目接近 n 时添加额外的线程可能会改善总处理能力，而在线程数目超过 n 时添加额外的线程将不起作用。事实上，太多的线程甚至会降低性能，因为它会导致额外的环境切换开销。线程池的最佳大小取决于可用处理器的数目以及工作队列中的任务的性质。若在一个具有 n 个处理器的系统上只有一个工作队列，其中全部是计算性质的任务，在线程池具有 n 或 n+1 个线程时一般会获得最大的 cpu 利用率。对于那些可能需要等待 i/o 完成的任务（例如，从套接字读取 http 请求的任务），需要让池的大小超过可用处理器的数目，因为并不是所有线程都一直在工作。通过使用概要分析，您可以估计某个典型请求的等待时间（wt）与服务时间（st）之间的比例。如果我们将这一比例称之为 wt/st，那么对于一个具有 n 个处理器的系统，需要设置大约 n*(1+wt/st) 个线程来保持处理器得到充分利用。处理器利用率不是调整线程池大小过程中的唯一考虑事项。随着线程池的增长，您可能会碰到调度程序、可用内存方面的限制，或者其它系统资源方面的限制，例如套接字、打开的文件句柄或数据库连接等的数目。