linux 线程堆栈线程占用堆空间还是栈空间

2025-1-10

大家好，如果您还对linux 线程堆栈不太了解，没有关系，今天就由本站为大家分享linux 线程堆栈的知识，包括线程占用堆空间还是栈空间的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！

Linux里面cpu占用太高排查思路是什么

思路就是top查看是什么进程占用高，一般是应用或者数据库，应用方面可以看看运行吐出日志是否有报错信息，查netstat连接应用端口的会话是不是有异常，数据库进程高，可以使用自带的检查命令后台看是否有执行很久的sql事务，锁等待频繁，报错日志等，找到问题针对性的优化，一步一步解决。

【C/C++ 线程】深入浅出:理解 std::thread 的局限性

在深入探索C++中的std::thread之前，我们首先需要理解其在现代编程中的重要性和应用。std::thread，或称作标准线程（Standard Thread），是C++11标准库中引入的一个重要组件，它允许开发者利用现代多核处理器的并发能力。

std::thread是C++标准库中的一个类，它提供了创建和管理线程的机制。线程（Thread）是程序执行的最小单元，它在操作系统层面被视为轻量级的进程。使用线程，可以在同一时间内执行多个任务，从而显著提升程序的性能和响应速度。

在现代软件开发中，尤其是在智能驾驶域控、中间件、音视频处理、TBox（车载终端）以及智能座舱等领域，多线程编程已经成为一种不可或缺的技能。例如，在智能驾驶领域，多线程可以用于同时处理多个传感器的数据，以实现更快的数据处理和决策制定。这不仅是对技术的一种需求，也是对开发者心理学上对效率和性能优化的渴望的反映。

然而，尽管std::thread提供了一种简便的方法来利用多线程编程的优势，但它也带来了一些局限性。接下来的章节将深入探讨这些局限性，以及可能的替代方案和扩展知识点。通过这种方式，我们可以更全面地理解 std::thread，并在合适的场景下做出明智的技术选择。

std::thread的核心设计理念之一是其立即启动（Immediate Launch）的机制。这意味着，一旦 std::thread对象被创建，它所代表的线程就会立即开始执行。这种设计选择背后的逻辑是简化线程的创建和管理。在C++中，这种立即执行的方式符合直观理解，开发者可以预期一旦线程对象被创建，线程就开始运行，而无需任何额外的启动调用。

std::thread的设计也遵循了资源获取即初始化（Resource Acquisition Is Initialization，简称 RAII）的原则。在C++中，RAII是一种有效的资源管理技术，用于确保在对象生命周期结束时，所持有的资源（如内存、文件句柄、线程等）能够被正确释放。

最后，std::thread的设计还旨在简化线程管理。通过提供一个简洁的API，它允许开发者轻松地创建和控制线程。这种简化对于快速开发和降低错误率是非常有益的，尤其是在复杂的应用程序中，如智能驾驶域控制器或中间件系统。

在前两章中，我们讨论了std::thread的设计理念和优势。本章将专注于 std::thread的局限性，并提供正确使用的方法。

线程堆栈大小是重要的性能参数。在复杂的应用中，如音视频处理或高级计算，适当的堆栈大小可以防止栈溢出，并提高效率。

虽然std::thread提供了对原生线程句柄的访问，这确实增加了一定程度的灵活性，但是关于将平台特定的线程（如通过 Windows的 _beginthreadex或 Linux的 pthread创建的线程）与 std::thread结合使用的问题，实际上并不那么直接。

所以，如果你需要设置线程堆栈大小，你可能需要完全依赖于平台特定的线程创建方法，并且独立于std::thread来管理这些线程。这意味着，尽管 std::thread提供了对原生线程句柄的访问，但这并不包括能够将通过平台特定方法创建的线程与 std::thread实例直接关联的能力。

因此，如果对线程堆栈大小有特殊要求，你可能需要在使用平台特定API创建线程的同时，放弃使用std::thread，或者只使用 std::thread的API来进行标准的线程创建和管理，而不涉及特殊的堆栈大小设置。

虽然std::thread本身不提供设置堆栈大小的功能，但它允许访问原始线程句柄（通过 native_handle方法）。这提供了一定程度的灵活性，使得开发者可以使用操作系统特定的功能，如设置线程优先级或处理器亲和性。

需要注意的是，使用原始句柄进行的任何操作都应当谨慎，以避免与std::thread的内部状态发生冲突。此外，这些操作可能会使得代码的移植性和可维护性降低。

std::thread最适用于那些不需要特别复杂线程管理的场景。它提供了一种简单直接的方式来利用多线程的优势，尤其适合于通用的并发任务。

在了解了std::thread的局限性之后，本章将探讨替代方案和相关的扩展知识，帮助开发者在面对不同的多线程需求时作出合适的技术选择。

在选择线程管理策略时，关键是要考虑应用程序的特定需求和目标平台的特性。std::thread提供了一种简单直观的线程创建和管理方式，适合于不需要复杂线程控制的场景。然而，当面对特殊的性能要求或平台特定的需求时，如线程堆栈大小的定制或优先级控制，开发者可能需要考虑使用平台特定的线程创建方法或更高级的并发管理工具。

随着多核处理器和并行计算的普及，多线程和并发编程在现代软件开发中的重要性将继续增长。C++标准在不断发展中，未来可能会引入更多高级的线程管理和并发控制功能。因此，保持对最新技术趋势的关注，并理解各种工具的优势和局限性，对于开发高效、稳定且可维护的软件至关重要。

std::thread作为C++11引入的一个重要特性，为C++程序员提供了一种方便的方式来利用多线程编程的优势。尽管它在某些方面有其局限性，但通过结合其他并发管理工具和平台特定的API，开发者可以充分利用多线程编程的强大能力。

通过综合考虑这些因素，我们可以在不同的应用场景中做出明智的技术选择，有效地解决并发编程中的挑战。

在我们的编程学习之旅中，理解是我们迈向更高层次的重要一步。然而，掌握新技能、新理念，始终需要时间和坚持。

通过理解和解决这些问题，我们不仅可以修复当前的代码，更可以提升我们的编程能力，防止在未来的项目中犯相同的错误。

我鼓励大家积极参与进来，不断提升自己的编程技术。

如何分析线程堆栈

JVM线程堆栈是一个给定时间的快照，它能向你提供所有被创建出来的Java线程的完整清单.

每一个被发现的Java线程都会给你如下信息:

–线程的名称；经常被中间件厂商用来识别线程的标识，一般还会带上被分配的线程池名称以及状态(运行，阻塞等等.)

–线程类型&优先级，例如: daemon prio=3**中间件程序一般以后台守护的形式创建他们的线程，这意味着这些线程是在后台运行的；它们会向它们的用户提供服务，例如：向你的Java EE应用程序**

– Java线程ID，例如: tid=0x000000011e52a800**这是通过 java.lang.Thread.getId()获得的Java线程ID，它常常用自增长的长整形 1..n**实现

–原生线程ID，例如: nid=0x251c**，之所以关键是因为原生线程ID可以让你获得诸如从操作系统的角度来看那个线程在你的JVM中使用了大部分的CPU时间等这样的相关信息.**

– Java线程状态和详细信息，例如: waiting for monitor entry [0xfffffffea5afb000] java.lang.Thread.State: BLOCKED(on object monitor)

**可以快速的了解到线程状态极其当前阻塞的可能原因**

– Java线程栈跟踪；这是目前为止你能从线程堆栈中找到的最重要的数据.这也是你花费最多分析时间的地方，因为Java栈跟踪向提供了你将会在稍后的练习环节了解到的导致诸多类型的问题的根本原因，所需要的90%的信息。

– Java堆内存分解;从HotSpot VM 1.6版本开始，在线程堆栈的末尾处可以看到HotSpot的内存使用情况，比如说Java的堆内存(YoungGen, OldGen)& PermGen空间。这个信息对分析由于频繁GC而引起的问题时，是很有用的。你可以使用已知的线程数据或模式做一个快速的定位。

Heap

PSYoungGen total 466944K, used 178734K [0xffffffff45c00000, 0xffffffff70800000, 0xffffffff70800000)

eden space 233472K, 76% used [0xffffffff45c00000,0xffffffff50ab7c50,0xffffffff54000000)

from space 233472K, 0% used [0xffffffff62400000,0xffffffff62400000,0xffffffff70800000)

to space 233472K, 0% used [0xffffffff54000000,0xffffffff54000000,0xffffffff62400000)

PSOldGen total 1400832K, used 1400831K [0xfffffffef0400000, 0xffffffff45c00000, 0xffffffff45c00000)

object space 1400832K, 99% used [0xfffffffef0400000,0xffffffff45bfffb8,0xffffffff45c00000)

PSPermGen total 262144K, used 248475K [0xfffffffed0400000, 0xfffffffee0400000, 0xfffffffef0400000)

object space 262144K, 94% used [0xfffffffed0400000,0xfffffffedf6a6f08,0xfffffffee0400000)

线程堆栈信息大拆解

为了让大家更好的理解，给大家提供了下面的这张图，在这张图中将HotSpot VM上的线程堆栈信息和线程池做了详细的拆解，如下图所示：

上图中可以看出线程堆栈是由多个不同部分组成的。这些信息对问题分析都很重要，但对不同的问题模式的分析会使用不同的部分（问题模式会在后面的文章中做模拟和演示。）

现在通过这个分析样例，给大家详细解释一下HoteSpot上线程堆栈信息中的各个组成部分：

# Full thread dump标示符

“Full thread dump”是一个全局唯一的关键字，你可以在中间件和单机版本Java的线程堆栈信息的输出日志中找到它（比如说在UNIX下使用：kill-3<PID>）。这是线程堆栈快照的开始部分。

Full thread dump Java HotSpot(TM) 64-Bit Server VM(20.0-b11 mixed mode):

# Java EE中间件,第三方以及自定义应用软件中的线程

这个部分是整个线程堆栈的核心部分，也是通常需要花费最多分析时间的部分。堆栈中线程的个数取决你使用的中间件，第三方库（可能会有独立线程）以及你的应用程序（如果创建自定义线程，这通常不是一个很好的实践）。

在我们的示例线程堆栈中，WebLogic是我们所使用的中间件。从Weblogic 9.2开始,会使用一个用“’weblogic.kernel.Default(self-tuning)”唯一标识的能自行管理的线程池

"[STANDBY] ExecuteThread:'414' for queue:'weblogic.kernel.Default(self-tuning)'" daemon prio=3 tid=0x000000010916a800 nid=0x2613 in Object.wait() [0xfffffffe9edff000]

java.lang.Thread.State: WAITING(on object monitor)

at java.lang.Object.wait(Native Method)

- waiting on<0xffffffff27d44de0>(a weblogic.work.ExecuteThread)

at java.lang.Object.wait(Object.java:485)

at weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:160)

- locked<0xffffffff27d44de0>(a weblogic.work.ExecuteThread)

at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)

# HotSpot VM线程

这是一个有Hotspot VM管理的内部线程，用于执行内部的原生操作。一般你不用对此操太多心，除非你(通过相关的线程堆栈以及 prstat或者原生线程Id)发现很高的CPU占用率.

"VM Periodic Task Thread" prio=3 tid=0x0000000101238800 nid=0x19 waiting on condition

# HotSpot GC线程

当使用 HotSpot进行并行 GC(如今在使用多个物理核心的环境下很常见),默认创建的HotSpot VM或者每个JVM管理一个有特定标识的GC线程时.这些GC线程可以让VM以并行的方式执行其周期性的GC清理,这会导致GC时间的总体减少；与此同时的代价是CPU的使用时间会增加.

"GC task thread#0(ParallelGC)" prio=3 tid=0x0000000100120000 nid=0x3 runnable

"GC task thread#1(ParallelGC)" prio=3 tid=0x0000000100131000 nid=0x4 runnable

………………………………………………………………………………………………………………………………………………………………

这事非常关键的数据，因为当你遇到跟GC有关的问题，诸如过度GC、内存泄露等问题是，你将可以利用这些线程的原生Id值关联的操作系统或者Java线程，进而发现任何对CPI时间的高占用.未来的文章你将会了解到如何识别并诊断这样的问题.

# JNI全局引用计数

JNI(Java本地接口)的全局引用就是从本地代码到由Java垃圾收集器管理的Java对象的基本的对象引用.它的角色就是阻止对仍然在被本地代码使用，但是技术上已经不是Java代码中的“活动的”引用了的对象的垃圾收集.

同时为了侦测JNI相关的泄露而留意JNI引用也很重要.如果你的程序直接使用了JNI，或者像监听器这样的第三方工具，就容易造成本地的内存泄露.

JNI global references: 1925

# Java堆栈使用视图

这些数据被添加回了 JDK 1.6，向你提供有关Hotspot堆栈的一个简短而快速的视图.我发现它在当我处理带有过高CPU占用的GC相关的问题时非常有用，你可以在一个单独的快照中同时看到线程堆栈以及Java堆的信息，让你当时就可以在一个特定的Java堆内存空间中解析（或者排除）出任何的关键点.你如在我们的示例线程堆栈中所见，Java的堆 OldGen超出了最大值!