Java多线程问题

1） ：单线程应用程序是否仅在用户的CPU上使用1个线程？提供更多线程会使用多个CPU核吗？如果声明的线程数超过用户的CPU数，会发生什么情况

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

3） 当前位置我正在做游戏，收集垃圾时偶尔会有明显的口吃。将垃圾回收器放在自己的线程中可以解决这个问题吗？

1）除了JVM可以创建自己的线程之外，应用程序可能只使用1个线程（例如，垃圾回收在自己的线程（或更多线程）中分离）。更多的线程使用更多的CPU，如果您的线程数超过CPU，调度程序将使线程轮流（上下文切换）

2） 过多的上下文切换（调度程序必须在您创建的所有线程之间来回切换，并给它们一个运行的机会）和操作系统线程的耗尽（要么创建太多线程，要么由于它们从未完成任务而丢失线程）将导致性能问题

3） 垃圾收集器已在其自己的线程（或多个线程）中。调优GC和避免创建过多的垃圾都是很好的技巧

请参阅以了解线程可以加快任务速度的限制。

---

您将锁定排除在问题之外，但过度锁定是性能的主要障碍。

您提出的问题：

是的，一个线程意味着一个CPU线程。附加线程可以使用附加CPU，只要它们有工作要做。如果您创建的线程比CPU多，它们将争夺CPU时间，结果往往会更慢。一些CPU使用超线程，并公开比实际内核更多的线程（有时这会提高性能）。使用

Runtime.getRuntime.availableProcessors（）

显示建议的线程计数

是的，线程的创建和销毁并不便宜，而且有一个简单的方法。因此，线程池和重用是一种非常常见的模式。不要为每个方法调用创建线程

垃圾收集器已经在不同的线程中完成了它的工作，但它必须在GC的至少部分时间内引起“停止世界”暂停，以便标记要收集的死对象 您需要的问题和答案，对于您没有问的问题：

问：我怎样才能让这个过程更快

答：有几种方法：

• 概要：找出你的程序中的瓶颈所在，并关注它。10%的代码通常占用90%的运行时间
• 在尝试优化实现之前，请关注算法。唯一比以2倍的速度进行昂贵的操作更好的事情是永远不必这样做。延迟加载和缓存结果可以节省大量时间
• 使用一个主线程进行渲染和用户交互，并在此处尽可能少地进行实际工作。这使得系统对用户做出响应。渲染只应在某些内容发生更改时创建新对象
• 将工作队列和工作线程池用于长时间运行的任务，特别是网络请求或磁盘I/O，这将阻止渲染和UI线程。所有实际工作都应该是异步的
• 产生尽可能少的垃圾-不要在不需要的时候制造和销毁对象。垃圾收集很少会成为Java程序的重要瓶颈
• 磁盘I/O使用单个线程，网络I/O使用池中的多个线程，每个CPU使用一个工作线程

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

---

如果您得到明显的垃圾收集暂停，那么您可能做错了什么。垃圾收集经过优化，以最少的时间获得最多的结果。大多数情况下，GC暂停几毫秒就可以完成一个小GC（除非我们讨论的是4+GB的堆）。不要显式调用System.gc（），否则您将强制执行不必要的工作，并使世界暂停。

垃圾收集器确实在自己的线程（或多个线程）中运行。尽管所有GC实现都有一个“停止世界”的时刻，但调优GC会产生巨大的影响。（首先创建更少的垃圾也有帮助。：）这也回答了第一个问题：不，即使是“单线程”Java应用程序也会有多个线程运行。但我看到的主要问题是，您认为使用多线程是解决性能问题的一种方法。事实上，这种情况很少发生，在一个问题上抛出越来越多的线程会很快开始降低性能一堆会导致性能问题的代码，让java自己来做。我知道不要经常调用它，但我注意到了结巴，所以为了测试它，我绑定了System.gc（）；当我按下一个键时，肯定会有口吃。过多的上下文切换也会导致性能问题！这些将是我的下一个问题@MitchWeaver这几乎就像我以前遇到过这个问题；）