Java多线程问题

Question

1）：单线程应用程序在用户的CPU上只会使用1个线程吗？ 分配更多线程会使用多个CPU内核吗？ 如果声明的线程数超过了用户CPU的数量，会发生什么？

2）：只要您的方法没有同步问题或其他问题，对每个方法创建新线程是否会对性能造成不利影响？

3）：我在做游戏，有时候收集垃圾时会有明显的断断续续。 将垃圾收集器放在其自己的线程中是否可以解决此问题？

Answer 1

您提出的问题：

1. 是的，一个线程意味着一个CPU线程。 只要有其他工作要做，其他线程就可以使用其他CPU。 如果创建的线程多于CPU，它们将争夺CPU时间，并且结果通常会更慢。 一些CPU使用超线程并且公开比实际内核更多的线程（有时这会带来性能上的好处）。 使用Runtime.getRuntime.availableProcessors()来显示建议的线程数。
2. 是的，创建和销毁线程并不便宜，并且每个线程都有大量开销 。 因此，池化和重用线程是一种极为常见的模式。 不要为每个方法调用都创建一个线程。
3. 垃圾收集器已经在单独的线程中完成其工作，但是必须为GC的至少一部分造成“停止世界”暂停，以便将死对象标记为要收集。

您不需要的问题和答案：

问：如何使此过程更快？

答：几种方法：

• 配置文件：查找程序瓶颈所在的位置，并专注于此。 您的代码的10％通常会占用90％的运行时间。
• 在尝试优化实现之前，请先关注算法。 唯一比做2倍昂贵的操作更好的是， 永远不必这样做。 延迟加载和缓存结果可能会节省大量时间。
• 使用一个主线程进行渲染和用户交互，并在此处进行尽可能少的实际工作。 这使系统看起来对用户有所响应。 渲染仅应在发生更改时创建新对象。
• 将工作队列和工作线程池用于长时间运行的任务， 尤其是会阻塞呈现和UI线程的网络请求或磁盘I / O。 您的所有实际工作都应该是异步的。
• 生成尽可能少的垃圾-不需要时不要制造和销毁对象。 垃圾回收很少会成为Java程序的重大瓶颈。
• 将单个线程用于磁盘I / O，将池中的多个线程用于网络I / O，每个CPU使用一个工作线程。

编辑：在有人抱怨之前，异步I / O或非阻塞I / O的性能比网络请求的线程池要好，但是对于新开发人员来说，正确使用它们也更为复杂。 只要您不写太多关于网络的内容，适度大小的线程池就足以使网络连接饱和，尽管有延迟。

如果您收到明显的垃圾收集暂停，则可能是您做错了什么。 已对垃圾收集进行了优化，以在最短的时间内获得最佳结果。 在大多数情况下，进行次要GC的GC暂停需要几毫秒的时间（除非我们要谈论的是4 GB以上的堆）。 不要显式调用System.gc（），否则将迫使不必要的工作和巨大的暂停。

Answer 2

1）您的应用程序只能使用1个线程，此外JVM可以创建自己的线程（例如，垃圾回收是在其自己的线程（或更多线程）中分离出来的）。 更多的线程使用更多的CPU，如果您拥有的线程比CPU多，则调度程序使线程轮流使用（上下文切换）。

2）过多的上下文切换（由于调度程序必须在您创建的所有线程之间来回切换，使它们有运行的机会）和OS线程用完（要么创建过多线程，要么由于它们永远不会丢失它们）完成任务）将导致性能问题。

3）垃圾收集器已经在其自己的线程（或多个线程）中。 调优GC并避免产生过多的垃圾都是不错的提示。

请参阅阿姆达尔定律 ，以了解可以加快任务执行速度的线程数量的限制。 您从问题中排除了锁定，但是过度锁定是性能的主要障碍。