跨平台C/C++开发：统一获取CPU核心数、线程ID与进程ID的工程实践

1. 项目概述与核心价值

在C/C++开发中，尤其是在进行性能优化、多线程编程、资源管理或系统监控时，获取当前CPU核心数量、当前线程ID以及当前进程ID是三个非常基础且高频的需求。听起来简单，但当你需要让代码在MacOS、Windows、Linux乃至Android NDK（API Level 21+）等多个主流平台上都能稳定运行时，问题就变得复杂了。每个操作系统都提供了自己的一套API，函数名、头文件、甚至获取方式都大相径庭。直接使用平台特定代码，会让你的项目充斥着大量的#ifdef宏，代码臃肿且难以维护。

这个项目的核心价值，就是封装一套简洁、统一、线程安全的接口，屏蔽底层平台的差异。开发者只需要调用如get_cpu_core_count()、get_current_thread_id()、get_current_process_id()这样的函数，就能在所有目标平台上获得正确的结果。这不仅仅是写几个#ifdef那么简单，它涉及到对各个平台API的深入理解、对边缘情况的处理（比如虚拟核心与物理核心的区分）、以及对未来平台兼容性的考量。无论是开发一个跨平台的游戏引擎、一个高性能的计算库，还是一个需要精细控制线程的系统服务，这套工具都是基础设施中的基础设施。

2. 多平台API深度解析与设计思路

要实现跨平台兼容，首先得摸清每个平台的“脾气”。我们不能简单地罗列API，而是要理解它们背后的设计哲学和潜在陷阱，这样才能做出健壮的封装。

2.1 CPU核心数量获取：不只是sysconf

获取CPU核心数，最直观的想法是“有多少个逻辑处理器可用”。但这里有几个层次：物理核心、逻辑核心（支持超线程的CPU，逻辑核心数通常是物理核心数的两倍）、以及当前进程可用的核心数（可能受CPU亲和性或容器限制）。

• Linux/macOS (POSIX 系统): 最常用的是sysconf(_SC_NPROCESSORS_ONLN)，它返回当前在线的逻辑处理器数量。这个值通常是准确的，也反映了系统的即时状态（比如有核心被热拔插）。在Linux上，我们也可以通过解析/proc/cpuinfo文件或使用sysconf(_SC_NPROCESSORS_CONF)（系统配置的处理器数）来获取，但_SC_NPROCESSORS_ONLN是动态的、更可靠的选择。对于只想获取物理核心数的场景，在Linux上可能需要解析/proc/cpuinfo中的"cpu cores"字段，或使用sysconf(_SC_NPROCESSORS_CONF)并结合其他信息判断，但这超出了基础需求，我们的封装优先保证逻辑核心数的一致性和可用性。

• Windows: Windows提供了GetSystemInfo和GetLogicalProcessorInformation两个主要API。GetSystemInfo返回的SYSTEM_INFO.dwNumberOfProcessors字段在较新系统上通常也表示逻辑处理器数，但文档指出其可能不代表当前活动的处理器数。更现代、更准确的方法是使用GetLogicalProcessorInformation函数，它返回一个结构体数组，详细描述了处理器的关系（包括核心、缓存、NUMA节点）。我们可以遍历这个数组，统计RelationProcessorCore关系的条目数来得到物理核心数，或者直接统计RelationProcessorCore中每个条目的ProcessorMask中设置的位数来得到逻辑核心数。为了与POSIX行为保持一致（获取逻辑核心数），我们通常采用后一种方式。

• Android NDK (API >= 21): Android基于Linux，但在NDK环境下，直接使用sysconf是可行的。更“Android”的方式是使用<sys/sysconf.h>。从API Level 21开始，sysconf的支持是完整的。我们也可以使用<cpu-features.h>中的android_getCpuCount()函数，它内部也是调用sysconf，但提供了更明确的语义。

设计思路：我们的封装函数get_cpu_core_count()将优先返回系统的逻辑处理器数量。在Windows上，使用GetLogicalProcessorInformation来确保获取最准确的信息；在其他平台，统一使用sysconf(_SC_NPROCESSORS_ONLN)。这样保证了接口行为的一致性。

2.2 线程ID与进程ID：标识的奥秘

线程ID和进程ID是操作系统调度和管理的核心标识符。它们的类型和获取方式同样因平台而异。

• 线程ID (Thread ID):

  • POSIX (Linux/macOS/Android): 使用pthread_t类型表示线程ID，通过pthread_self()函数获取。但需要注意的是，pthread_t可能是一个结构体（如在旧版macOS），不能直接当作整数打印或比较。为了得到一个可移植的数值型线程ID，通常使用pthread_getthreadid_np()(macOS)或syscall(SYS_gettid)(Linux)来获取系统级的线程ID。更简单一致的方法是，在POSIX系统上，我们有时直接使用pthread_self()返回的pthread_t，在需要数值时，可以将其转换为uintptr_t或使用平台特定方法。一个更好的跨平台方案是，在创建线程时，自己维护一个简单的整数ID。
  • Windows: 使用GetCurrentThreadId()函数，直接返回一个DWORD（32位无符号整数），简单明了。
  • 设计难点：真正的难点在于提供一个跨平台且可比较的线程ID。pthread_t不能保证在不同平台间可以像整数一样比较。因此，我们的封装目标可以有两种：1) 返回一个平台相关的ID（如pthread_t或DWORD），调用者自己处理比较；2) 返回一个我们内部统一生成的、简单的、递增的整数ID。对于大多数日志记录、调试场景，方案一通常足够。如果需要严格的跨平台比较，方案二更可靠，但需要管理线程本地存储。

• 进程ID (Process ID):

  • POSIX: 使用pid_t类型，通过getpid()函数获取。这是一个整数。
  • Windows: 使用GetCurrentProcessId()函数，返回DWORD。
  • 相对简单：进程ID的获取在所有平台上都非常直接，且都是整数类型，封装起来最容易。

设计思路：对于进程ID，我们可以直接封装，返回一个uint32_t或uint64_t。对于线程ID，为了实用性和简化，我们的get_current_thread_id()函数可以返回一个uint64_t类型的值。在Windows上，直接返回GetCurrentThreadId()；在POSIX平台上，我们面临选择：返回一个从pthread_t派生出的唯一数值。一个常见且相对可靠的方法是使用pthread_getthreadid_np()(BSD/macOS)或syscall(SYS_gettid)(Linux)。为了代码简洁，我们可以定义一个内部函数，在支持pthread_getthreadid_np的系统上使用它，否则将pthread_self()指针转换为uintptr_t作为一个唯一标识（但这并非真正的系统线程ID，且在同一进程内唯一）。对于高要求的场景，明确说明其局限性。

2.3 多平台兼容性架构设计

核心是使用预编译宏进行条件编译。这是C/C++跨平台代码的基石。

// platform_detect.h #pragma once #if defined(_WIN32) || defined(_WIN64) #define PLATFORM_WINDOWS 1 #ifndef WIN32_LEAN_AND_MEAN #define WIN32_LEAN_AND_MEAN #endif #include <windows.h> #include <processthreadsapi.h> // For GetCurrentProcessId, GetCurrentThreadId #include <sysinfoapi.h> // For GetSystemInfo, GetLogicalProcessorInformation #elif defined(__APPLE__) && defined(__MACH__) #define PLATFORM_MACOS 1 #include <unistd.h> #include <sys/sysctl.h> #include <pthread.h> #include <mach/mach.h> #elif defined(__ANDROID__) #define PLATFORM_ANDROID 1 #include <unistd.h> #include <sys/sysconf.h> // Android NDK 中 pthread 也是可用的 #include <pthread.h> #elif defined(__linux__) #define PLATFORM_LINUX 1 #include <unistd.h> #include <sys/sysconf.h> #include <pthread.h> // 对于 syscall(SYS_gettid) #include <sys/syscall.h> #include <unistd.h> #else #error "Unsupported platform" #endif

在实现文件中，我们再根据这些宏定义，编写不同平台的实现代码。头文件system_info.h则提供统一的API接口。

注意：宏定义的名字（如PLATFORM_WINDOWS）要清晰、独特，避免与第三方库或未来系统头文件中的宏冲突。WIN32_LEAN_AND_MEAN宏可以加快Windows头文件的编译速度，排除一些不常用的API。

3. 核心函数实现与代码详解

接下来，我们逐一实现这三个核心函数。我会提供详细的代码和关键注释。

3.1get_cpu_core_count()实现

// system_info.c #include "system_info.h" #include "platform_detect.h" #include <stdint.h> uint32_t get_cpu_core_count() { static uint32_t core_count = 0; // 简单的缓存，避免多次调用系统API (非线程安全，初始化时调用) if (core_count > 0) { return core_count; } uint32_t count = 0; #if PLATFORM_WINDOWS // 方法1: 使用 GetLogicalProcessorInformation (推荐，信息最全) PSYSTEM_LOGICAL_PROCESSOR_INFORMATION buffer = NULL; DWORD returnLength = 0; // 第一次调用获取所需缓冲区大小 BOOL result = GetLogicalProcessorInformation(NULL, &returnLength); if (result == FALSE && GetLastError() == ERROR_INSUFFICIENT_BUFFER) { buffer = (PSYSTEM_LOGICAL_PROCESSOR_INFORMATION)malloc(returnLength); if (buffer) { result = GetLogicalProcessorInformation(buffer, &returnLength); if (result == TRUE) { DWORD byteOffset = 0; PSYSTEM_LOGICAL_PROCESSOR_INFORMATION ptr = buffer; while (byteOffset + sizeof(SYSTEM_LOGICAL_PROCESSOR_INFORMATION) <= returnLength) { if (ptr->Relationship == RelationProcessorCore) { // 每个核心的 ProcessorMask 可能包含多个逻辑处理器（超线程） // 计算掩码中设置的位数，即此核心的逻辑处理器数 ULONG_PTR mask = ptr->ProcessorMask; while (mask) { if (mask & 1) { count++; } mask >>= 1; } } byteOffset += sizeof(SYSTEM_LOGICAL_PROCESSOR_INFORMATION); ptr++; } } free(buffer); } } // 如果上述方法失败，回退到 GetSystemInfo if (count == 0) { SYSTEM_INFO sysInfo; GetSystemInfo(&sysInfo); count = sysInfo.dwNumberOfProcessors; } #elif PLATFORM_MACOS // macOS 可以使用 sysctl 或 sysconf int mib[2]; size_t len = sizeof(count); mib[0] = CTL_HW; mib[1] = HW_AVAILCPU; // 或者 HW_NCPU (已弃用), HW_AVAILCPU 返回可用数 if (sysctl(mib, 2, &count, &len, NULL, 0) == 0 && count > 0) { // 成功 } else { // 回退到 sysconf long sc_count = sysconf(_SC_NPROCESSORS_ONLN); count = (sc_count > 0) ? (uint32_t)sc_count : 1; } #elif PLATFORM_LINUX || PLATFORM_ANDROID // Linux 和 Android 使用 sysconf long sc_count = sysconf(_SC_NPROCESSORS_ONLN); count = (sc_count > 0) ? (uint32_t)sc_count : 1; #else // 未知平台，返回一个安全值 count = 1; #endif core_count = (count == 0) ? 1 : count; // 确保至少为1 return core_count; }

关键点解析：

1. Windows的GetLogicalProcessorInformation：这是最准确的方法。它需要动态分配内存。我们遍历返回的数组，寻找RelationProcessorCore类型的关系。每个核心的ProcessorMask是一个位掩码，每一位代表一个逻辑处理器。通过统计所有核心掩码中设置的位数，我们得到总的逻辑处理器数。这比GetSystemInfo更精确，尤其是在处理超线程和处理器组时。
2. 缓存机制：CPU核心数量在程序运行期间通常不会改变（除非在支持热插拔的特定服务器上）。我们在函数内部使用static变量进行缓存，避免每次调用都执行昂贵的系统调用。注意，这个简单的缓存不是线程安全的，但考虑到该函数通常在程序初始化时调用，且值不变，这个风险是可接受的。如果要求绝对线程安全，可以使用std::call_once(C++)或双检查锁。
3. 错误处理与回退：每个平台都应有回退方案。比如Windows的GetLogicalProcessorInformation可能失败（权限不足或系统版本问题），我们就回退到GetSystemInfo。sysconf或sysctl调用失败时，我们返回一个默认值1，防止程序因无法获取核心数而崩溃。

3.2get_current_thread_id()实现

uint64_t get_current_thread_id() { uint64_t tid = 0; #if PLATFORM_WINDOWS tid = (uint64_t)GetCurrentThreadId(); #elif PLATFORM_MACOS // macOS 10.6+ 可以使用 pthread_threadid_np uint64_t mac_tid; if (pthread_threadid_np(pthread_self(), &mac_tid) == 0) { tid = mac_tid; } else { // 失败回退：将 pthread_t 指针转换为整数（不保证系统唯一，但进程内唯一） tid = (uint64_t)(uintptr_t)pthread_self(); } #elif PLATFORM_LINUX // Linux 下使用 syscall 获取内核线程ID (gettid) tid = (uint64_t)syscall(SYS_gettid); #elif PLATFORM_ANDROID // Android 情况复杂。高版本API（如API 30+）有gettid。 // 为了兼容API 21+，我们使用与Linux相同的方法，但需要注意syscall号可能不同。 // 更安全的方法是使用 `pthread_gettid_np` (如果可用) 或回退。 // 这里我们使用一个相对通用的方法：尝试syscall，失败则回退。 #if __ANDROID_API__ >= 30 tid = (uint64_t)gettid(); #else // 尝试 SYS_gettid syscall tid = (uint64_t)syscall(__NR_gettid); // __NR_gettid 在 bionic 中定义 if ((long)tid == -1) { // syscall 可能失败 // 回退到 pthread_self 转换 tid = (uint64_t)(uintptr_t)pthread_self(); } #endif #else // 未知平台，生成一个进程内唯一的ID（简易方案，非生产环境） static uint64_t fallback_counter = 0; tid = ++fallback_counter; #endif return tid; }

关键点解析：

1. 平台差异处理：这是实现中最棘手的部分。Windows最简单。macOS推荐使用pthread_threadid_np，它直接返回系统级的64位线程ID。Linux的syscall(SYS_gettid)是标准做法。
2. Android NDK的复杂性：Android的Bionic C库在不同API Level上支持度不同。gettid()函数在API 30及以上才正式声明。对于低版本API，使用syscall(__NR_gettid)是常见做法，但__NR_gettid这个宏不一定在所有架构和版本中都存在。最保守的方案是，在Android上，如果上述方法都不可用，就回退到将pthread_self()转换为整数。这得到的不是系统全局唯一的线程ID，但在当前进程内是唯一的，对于很多日志和调试场景已经足够。如果项目需要严格的系统级线程ID，可能需要为不同的Android API Level编写更精细的条件代码。
3. 返回值类型：我们统一返回uint64_t，足以容纳所有平台的线程ID。即使在32位系统上，DWORD和pid_t也能安全存入。

3.3get_current_process_id()实现

uint64_t get_current_process_id() { uint64_t pid = 0; #if PLATFORM_WINDOWS pid = (uint64_t)GetCurrentProcessId(); #elif PLATFORM_MACOS || PLATFORM_LINUX || PLATFORM_ANDROID pid = (uint64_t)getpid(); #else pid = 0; // 未知平台 #endif return pid; }

这个函数的实现最为直接，因为所有平台都有对应的、行为一致的函数。

3.4 统一的头文件

// system_info.h #pragma once #include <stdint.h> // 为了使用 uint32_t, uint64_t #ifdef __cplusplus extern "C" { #endif /** * @brief 获取当前系统的逻辑CPU核心数量。 * @return 逻辑处理器核心数量。如果无法获取，返回1。 */ uint32_t get_cpu_core_count(void); /** * @brief 获取当前线程的ID。 * @return 当前线程的ID。返回值类型为uint64_t以兼容所有平台。 * @note 在部分平台（如某些Android版本），此ID可能并非系统全局唯一，但在进程内唯一。 */ uint64_t get_current_thread_id(void); /** * @brief 获取当前进程的ID。 * @return 当前进程的ID。 */ uint64_t get_current_process_id(void); #ifdef __cplusplus } #endif

头文件使用extern "C"包裹，确保在C++项目中也能正确链接。函数声明清晰，并附带了简单的文档注释。

4. 编译、测试与常见问题排查

实现代码后，下一步是确保它能正确编译并在各个平台上运行。

4.1 多平台编译指南

你需要为每个目标平台准备构建系统（如CMake、Makefile）。

CMake示例 (CMakeLists.txt):

cmake_minimum_required(VERSION 3.10) project(SystemInfo LANGUAGES C) # 根据平台添加编译定义或链接库不是必须的，因为我们都用了系统头文件。 # 但可以设置一些全局属性。 set(CMAKE_C_STANDARD 11) set(CMAKE_C_STANDARD_REQUIRED ON) # 创建静态库 add_library(system_info STATIC src/system_info.c src/platform_detect.h src/system_info.h) # 或者直接编译为可执行文件进行测试 add_executable(test_system_info test/test_main.c) target_link_libraries(test_system_info system_info) # 在Windows上，需要链接特定的系统库（实际上GetLogicalProcessorInformation在kernel32.lib，通常自动链接） if(WIN32) # 通常不需要显式链接，但如果你遇到链接错误，可以取消注释 # target_link_libraries(system_info kernel32 user32) endif()

编译命令:

• Linux/macOS:gcc -std=c11 -o test_system_info system_info.c test_main.c -lpthread(链接pthread库，某些平台获取线程ID可能需要)
• Windows (MSVC):cl /Fe:test_system_info.exe system_info.c test_main.c
• Android NDK: 使用ndk-build或CMake工具链，确保Android.mk或CMakeLists.txt中指定了正确的API级别（-DANDROID_PLATFORM=android-21）。

4.2 编写测试程序

一个简单的测试程序可以验证功能：

// test_main.c #include <stdio.h> #include <stdlib.h> #include "system_info.h" #include <threads.h> // 或用 pthread.h void print_system_info() { printf("CPU Core Count: %u\n", get_cpu_core_count()); printf("Current Process ID: %llu\n", (unsigned long long)get_current_process_id()); printf("Main Thread ID: %llu\n", (unsigned long long)get_current_thread_id()); } #ifdef USE_THREADS int thread_func(void* arg) { (void)arg; printf("Child Thread ID: %llu\n", (unsigned long long)get_current_thread_id()); return 0; } #endif int main() { print_system_info(); #ifdef USE_THREADS // 创建子线程测试线程ID thrd_t thread; if (thrd_create(&thread, thread_func, NULL) == thrd_success) { thrd_join(thread, NULL); } #endif return 0; }

4.3 常见问题与排查技巧实录

在实际集成和使用过程中，你可能会遇到以下问题：

1. Windows上GetLogicalProcessorInformation编译或链接错误

   • 现象：error LNK2001: 无法解析的外部符号 __imp_GetLogicalProcessorInformation。
   • 原因：虽然包含了<windows.h>和<sysinfoapi.h>，但链接器没有找到对应的库实现。这个函数在kernel32.lib中。
   • 解决：确保你的项目链接了kernel32.lib。在MSVC中，它通常是默认链接的。如果使用MinGW，编译时可能需要指定-lkernel32。在CMake中，可以添加target_link_libraries(your_target kernel32)。

2. Android NDK低版本API编译失败

   • 现象：error: use of undeclared identifier 'gettid'或syscall找不到SYS_gettid。
   • 原因：gettid()是glibc的函数，Bionic C库在低版本（API < 30）中没有公开声明。SYS_gettid这个系统调用号宏也可能因架构而异。
   • 解决：
     • 方案A（推荐）：接受在Android低版本上线程ID非系统唯一的限制，使用回退方案（pthread_self转换）。这对于大多数应用层日志记录是可接受的。
     • 方案B：为不同Android API Level编写条件更细致的代码。可以使用__ANDROID_API__宏判断，并尝试动态查找gettid符号（通过dlsym），但这增加了复杂性。
     • 方案C：如果你的应用最低支持API Level 30，那么直接使用gettid()。

3. macOS上pthread_threadid_np不可用

   • 现象：在很老的macOS系统（如10.5或更早）上编译失败。
   • 原因：pthread_threadid_np是macOS 10.6引入的。
   • 解决：我们的代码已经有了回退机制（转换pthread_self）。如果你需要支持更老的系统，确保回退逻辑有效。可以考虑在构建时通过宏检测SDK版本，或者运行时判断。

4. 获取的CPU核心数远大于物理核心数

   • 现象：在Intel CPU的Windows/Linux系统上，get_cpu_core_count()返回的数量是物理核心数的两倍。
   • 原因：这是正常的。函数设计返回的是逻辑处理器数量，对于支持超线程（Hyper-Threading）的CPU，每个物理核心会模拟出两个逻辑核心。我们的实现（特别是Windows的GetLogicalProcessorInformation统计）正确地反映了这一点。如果你的算法对物理核心数敏感，需要额外处理来识别物理核心数（例如，在Windows上统计RelationProcessorCore的条目数，而不是逻辑处理器数）。

5. 静态变量缓存的线程安全问题

   • 现象：在多线程环境下，首次同时调用get_cpu_core_count()可能导致缓存被多次初始化（虽然值相同），或者产生数据竞争（极罕见）。
   • 解决：对于这种“一次初始化”的场景，在C++11及以上环境中，可以使用std::call_once。在纯C或更早的C++中，可以使用双检查锁定模式（Double-Checked Locking），但要注意内存屏障。对于CPU核心数这种启动后基本不变的数据，一个更简单粗暴的方法是：在程序启动的单线程阶段（如main函数开头）主动调用一次这个函数进行初始化。

一个实用的调试技巧：在跨平台代码中，经常使用#error或#warning指令来在编译时检查平台宏。例如，在platform_detect.h的末尾，可以添加：

#if !(PLATFORM_WINDOWS || PLATFORM_MACOS || PLATFORM_LINUX || PLATFORM_ANDROID) #error "Failed to detect a supported platform! Check your compiler definitions." #endif

这能帮你快速发现平台检测失败的问题。

5. 高级话题与扩展思路

基础功能实现后，我们可以思考一些更深入的应用和优化。

5.1 性能考量与缓存策略

get_cpu_core_count()函数内部我们使用了static变量做缓存。在性能敏感的循环中，这避免了重复的系统调用。但是，在极少数动态CPU热插拔或CPU亲和性（affinity）发生变化的场景（如一些高性能计算任务手动绑核），缓存的值可能会过时。

• 扩展设计：可以提供两个版本的函数。

  • get_cpu_core_count(): 返回缓存的值，快速。
  • get_cpu_core_count_uncached(): 绕过缓存，直接查询系统，获取实时信息。让调用者根据场景选择。

• 缓存失效：在感知到系统配置可能改变时（例如，收到了特定的系统事件），可以提供一个invalidate_cpu_core_cache()函数来重置静态变量，迫使下次调用重新获取。

5.2 物理核心与逻辑核心的区分

如前所述，某些算法（如线程池大小设置，考虑CPU缓存亲和性的任务调度）需要知道物理核心数。

• 如何获取：

  • Windows: 使用GetLogicalProcessorInformation，统计Relationship为RelationProcessorCore的条目数。
  • Linux: 解析/proc/cpuinfo，查找"cpu cores"字段（位于每个处理器条目中，但每个物理核心的该字段值相同，需要去重），或者更现代的方法是解析/sys/devices/system/cpu/cpu*/topology/core_id。
  • macOS: 使用sysctl查询hw.physicalcpu。
  • Android: 情况复杂，通常可以认为sysconf(_SC_NPROCESSORS_ONLN)返回的是逻辑核心数，获取物理核心数需要类似Linux的解析方法，但NDK环境访问/proc或/sys可能受限。

• 实现建议：可以新增一个函数get_physical_cpu_core_count()，但要注意其实现比逻辑核心数更复杂，且在某些平台（特别是Android）可能不可靠。如果项目确实需要，建议将其作为可选的高级功能提供，并详细说明其平台局限性。

5.3 与C++标准库的集成

如果你的项目是C++，你可能会想，C++11的<thread>库不是提供了std::thread::hardware_concurrency()和std::this_thread::get_id()吗？

• std::thread::hardware_concurrency(): 这个函数的行为与我们的get_cpu_core_count()目标一致，返回逻辑处理器的数量。在背后，它通常也是调用sysconf或GetSystemInfo。使用标准库是首选，但我们的封装提供了更一致的跨平台行为（尤其是Windows上更精确的GetLogicalProcessorInformation）和更早的编译器支持（C++11之前）。
• std::this_thread::get_id(): 它返回一个std::thread::id类型，这是一个不可直接转换为整数的抽象类型。虽然可以输出或哈希，但无法得到一个简单的数值ID用于日志或快速比较。我们的get_current_thread_id()提供了数值型ID，更方便。
• 进程ID：C++标准库没有提供获取进程ID的函数。

因此，即使在C++项目中，这套C风格的API仍然有其价值，特别是在需要与C语言模块交互、需要数值型线程ID、或需要在C++11之前的环境中使用时。

5.4 在真实项目中的应用场景

1. 线程池配置：这是最典型的应用。创建线程池时，最优的线程数通常与CPU逻辑核心数相关（例如，核心数 * 2用于I/O密集型任务）。使用get_cpu_core_count()可以自动适配不同机器。
2. 性能监控与日志：在日志中输出进程ID和线程ID，对于诊断多进程、多线程应用的复杂问题至关重要。当分析日志文件时，你可以轻松地过滤出特定线程或进程的行为。
3. 资源命名与隔离：在创建命名的共享内存、信号量或文件锁时，将进程ID甚至线程ID包含在名称中，可以避免不同进程或线程间的命名冲突。
4. 调试与分析工具：开发性能剖析器(Profiler)或调试工具时，需要精确地跟踪每个线程的执行和资源消耗，线程ID是关键的关联标识。
5. 任务调度与负载均衡：在一些自定义的并行计算框架中，了解物理核心数有助于进行更精细的任务划分和数据局部性优化，减少缓存失效。

这套看似简单的工具函数，实际上是构建健壮、可移植、高性能的C/C++系统软件的基石之一。将它们封装好，并在项目初期就引入，能为后续的开发省去许多平台适配的麻烦。