线程基础概念：进程与线程的区别、线程的优缺点、线程的适用场景
各位同学，咱们今天聊聊多线程编程的根基——线程基础概念。说实话，我见过太多人一上来就撸线程代码，结果死锁、数据竞争搞得焦头烂额。其实啊，先把这些基础概念吃透，后面写代码会顺手得多。
一、进程与线程：到底差在哪？
先问个问题：你打开一个浏览器，又打开一个IDE，这俩是啥？对，是进程。那浏览器里开了十几个标签页呢？嗯，有些浏览器每个标签页是一个进程，有些是多个线程共享一个进程。
我个人的理解是这样的：进程是资源分配的最小单位，线程是CPU调度的最小单位。说白了，进程就像一家工厂，有自己的厂房、设备、原材料（独立的内存空间、文件句柄等）。线程呢，就是工厂里的工人，共享工厂的资源，但各自干各自的活。
核心区别一览：
| 对比项 | 进程 | 线程 |
|---|---|---|
| 地址空间 | 独立，互不干扰 | 共享同一进程的地址空间 |
| 资源开销 | 创建/销毁开销大（分配PCB、内存等） | 创建/销毁开销小（仅需栈和寄存器） |
| 通信方式 | IPC（管道、消息队列、共享内存等） | 直接读写全局变量（但需同步） |
| 健壮性 | 一个进程挂了不影响其他进程 | 一个线程崩溃可能导致整个进程退出 |
| 上下文切换 | 慢（切换页表、刷新TLB） | 快（只需保存/恢复寄存器） |
我在项目中遇到过这么个事：早期用多进程做网络爬虫，每个爬虫进程独立，结果内存直接爆了。后来改成多线程，共享一个请求队列和缓存，内存占用降了70%。这就是共享地址空间带来的好处。
二、线程的优缺点：别光看好处
很多新手一听多线程就兴奋，觉得能并行跑就是快。嗯，这里要注意，线程是把双刃剑。
优点
- 响应更快：UI线程不会被阻塞。你想想看，如果点击按钮后整个界面卡死，用户不骂娘才怪。
- 资源利用率高：线程间共享数据，不用搞复杂的IPC。我习惯用全局结构体加互斥锁，比进程间传消息简单多了。
- 创建销毁轻量：创建一个线程也就几微秒，进程可能要几十毫秒。在高并发场景下，这个差距是致命的。
- 多核利用：现在CPU动不动8核16核，不用多线程就是浪费硬件。
缺点
- 同步难题：数据竞争、死锁、活锁……我调过最恶心的一次bug，是三个线程互相等待，CPU空转但任务就是跑不完。查了两天才发现是加锁顺序不一致。
- 调试困难：单线程程序打断点就行。多线程？你打断点这个线程停了，其他线程还在跑，时序全乱了。
- 稳定性风险：一个线程的段错误，直接带走整个进程。我曾经在线上环境遇到过，一个子线程访问了野指针，整个服务挂了半小时。
- 性能瓶颈：线程不是越多越好。上下文切换也是有代价的，线程数超过CPU核心数太多，反而会变慢。
避坑指南：我曾经接手过一个项目，为了追求"极致性能"，开了200个线程做计算。结果呢？大部分时间花在线程切换上，实际吞吐量还不如16个线程。记住：线程数 = CPU核心数 × (1 + 等待时间/计算时间) 这个公式，别盲目开线程。
三、线程的适用场景：什么时候该用？
不是所有场景都适合多线程。我总结了几种典型情况：
- I/O密集型任务：比如网络请求、文件读写、数据库操作。线程在等待I/O时可以切出去干别的，提高CPU利用率。
- GUI应用：主线程处理界面事件，工作线程干重活。这样界面不会卡死。
- 计算密集型任务：但前提是任务可以拆分成独立子任务。比如图像处理，把一张大图切成四块，四个线程各算一块。
- 实时响应系统：比如游戏引擎，一个线程渲染，一个线程处理物理碰撞，一个线程加载资源。
反过来，什么时候不该用？任务本身很简单，几毫秒就搞定了，开线程反而增加开销。或者任务之间有强依赖关系，必须串行执行，那多线程也没意义。
我的个人习惯：先评估任务类型。如果是I/O密集，用线程池，线程数可以设到CPU核心数的2-4倍。如果是CPU密集，线程数等于核心数就行。别一上来就搞动态创建线程，那玩意儿开销不小。
四、知识体系梳理
为了让大家更直观地理解，我画了张图。这张图把进程与线程的关系、线程的优缺点、适用场景串在了一起。
这张图把今天讲的核心内容都串起来了。左边是进程和线程的对比，右边是优缺点，下面是适用场景。你想想看，搞懂了这些，后面学线程同步、线程池什么的，心里就有底了。
最后说一句：多线程不是银弹。我见过太多人为了用多线程而用多线程，结果代码复杂度翻倍，性能反而下降。记住一个原则：简单优先，多线程是手段不是目的。能用单线程解决的问题，别硬上多线程。
一句话总结：线程是轻量级的执行单元，共享进程资源，适合I/O密集和可并行计算场景，但要注意同步和稳定性问题。选不选多线程，先看场景再决定。