我在我无法决定采取何种解决的问题的中间。
问题是有点独特。 让我们把它这样，我是从网络连续地（每秒2至4倍）接收数据。 现在每个数据属于不同的，可以说，组。 现在，让我们把这些群体，1组，第2组等等。
每个组具有当从网络数据进行过滤，并添加到用于处理其相应的组专用的作业队列。
起初我创建每组专用线程这会从作业队列，并处理取数据，然后前进到阻塞状态（使用链接的阻塞队列）。
但是，我的高级建议，我应该使用线程池，因为这样线程不会被阻塞，并会被其他群体进行加工使用。
但这里是东西，数据即时得到足够快而且一个线程需要的时间来处理它是线程，可能的话，不会进入阻塞模式足够长的时间。 而这也将保证数据得到处理顺序，这在池，很少有机会，可能不会发生（作业1被前工作2完成）。
我的前辈也是这样的事实，池也将节省我们大量的内存，因为线程汇集（即时通讯思想他真的去了的话。）弯曲）。 虽然我不同意这一点，因为，我个人认为，合并或不是每个线程都有自己的堆栈存储器。 除非有东西在线程池这我不知道的。
最后一件事，我一直以为池有助于那里的工作出现在短的时间内一个巨大的数字。 这是有道理的，因为线程产卵将是一个性能杀，因为给init一个线程所花费的时间是很多比花费在做这项工作的时间多。 所以池有很大帮助这里。
但在我的情况下1组，第2组，......，groupN始终保持活力。 所以，如果有数据或不是仍然会在那里。 所以线程产卵是不是这里的问题。
我的前辈不相信，并希望我去与池解决方案，因为它的内存占用量是很大的。
因此，该走的路？
谢谢。
好问题。 池确实可以节省您的初始化时间，如你所说。 但它还有另一个方面：资源管理。 在这里，我要问你这个 - 究竟有多少组（只读专用线程），你有吗？ 做他们的应用程序的执行跨度期间动态增长？
例如，考虑一种情况：这个问题的答案是肯定的。 新的组类型动态添加。 在这种情况下，你可能不希望奉献AA线程各一个，因为没有对将要创建的组的量在技术上没有任何限制，你将创造大量的线程，系统将上下文切换，而不是做实事。 Threadpooling到rescue-线程池，可以指定对可以可能创建的线程数maxumal的限制，完全不考虑加载。 因此，应用程序可以从特定请求拒绝服务，但打通的那些得到妥善处理，并未导致系统资源。
考虑到上述情况，我很可能在你的情况，这是非常确定为每个组一个专门的线程！
这同样适用于你的高级的信念，这将节省内存。的确，一个线程占用的内存堆上，但是否真的那么多，如果它是一个预定义的金额，说5甚至10这大概是OK。 总之，除非你是，修道院和绝对相信，你确实有一个问题，你不应该使用池！
池是一个设计决策，而不是建筑之一。 你不能池在beggining并在情况下优化你发现你集中遇到性能问题后 ，有利于继续。
考虑到请求的序列（按顺序执行），这是无论您使用的是线程池或专用线。 顺序执行是再加上一个单一处理器线程的队列的一个属性。
创建一个线程将消耗资源，包括每个线程默认堆栈（IIR 512KB，但可配置）。 这样做的好处，以池为你承担有限的资源命中。 当然，你根据你要从事的工作需要你的大小池。
为了您的具体问题，我认为关键是要实际测量的性能/线程的使用等每个场景。 除非你遇到了限制，我也许就不会担心任何一种方式，除了以确保您可以交换成另一种实现，而不对应用程序产生重大影响。 请记住， 过早的优化是一切罪恶的根源 。 需要注意的是 ：
“过早的优化”是用来描述一种情况，一个程序员可以让性能因素影响的一段代码设计的短语。 这可能会导致一个设计，是不是干净，因为它可能已经或代码是不正确的，因为代码是由优化复杂，程序员通过优化分心。
