我是程序是用在工业自动设备里的大概有10个线程，线程里大多数时间都是等待传感器到位的
如
While(还没有到位)
{Thread.sleep(100);}
线程之间使用外部的变量进行简单的通信，线程里也会更新主界面的UI
Thread RunThread;//线程的声明
if (RunThread == null || (!RunThread.IsAlive))//线程的启动
{
RunThread = new Thread(RunPro);
RunThread.IsBackground = true;
RunThread.Start();
}
if (RunThread != null && RunThread.IsAlive)//线程的放弃
{RunThread.Abort();}
public void RunPro()///线程实现
{
this.Invoke(new Action(() => { 更新UI; }));//
}
我觉得10个线程太多了，可能会出现问题
是不是应该使用线程池呢？
1，我用以上那种方式会出现问题吗？
2，是不是应该用线程池，它有什么优点？
3，我上网找了一下发觉线程池例子很多，但不知用哪一个形式，求推荐一下？
------解决思路----------------------
性能问题，跟线程池没有直接关系，线程池只是“实现时”的一种工具而已。
这里的关键是，
1. 多个线程在那里来回切换地挂着windows线程调度系统，什么也不干在那儿玩儿cpu呢？
2. 而且任务的“出处”应该是比较底层高效率的机制，不是什么“你的程序去轮询它”而应该是它来调用你的程序.
3. 10个线程可能太少（也许需要350个），也可能太多（也许需要2个），想当然地弄一个“10线程”这个数字根本就是只中看的“阿斗”，它不能自动根据系统性能而调整并发数。
因此最根本的问题是，你搞什么“死循环、阻塞”的线程，这就是多余的。你还把这些都到线程池里，也不会有任何好处。如果你不能把流程设计为“在一定事件发生时才启动线程，并且在十几毫秒进行完处理之后就结束线程”，如果你还是“死循环、阻塞”的编程思想，那么谈“线程池”这个名词儿反而是没用的，因为你不会在十几毫秒之后把线程归还线程池的，线程池对你现在这种流程设计方式根本没用。
------解决思路----------------------
你这个应用,完全可以用单线程分别去处理,用不到多线程
反正你检测传感器是否到位的通信线程肯定也是只有1个,而不是开10个线程分别去检测10个传感器
你直接获取到传感器状态之后直接判断不好吗