CPU资源消耗问题
为什么有些进程会占满CPU？
- 计算密集型任务（涉及复杂数学运算（如矩阵乘法、FFT）和高频数据处理，导致CPU和内存占用高。）
- 优先级过高
- 允许进程几乎完全占用 CPU，除非被抢占
- 如果一个进程是多线程，并且线程绑定到多个核，它可能让多个核都满载
高负载：
计算密集：需要大量CPU/GPU计算（如浮点运算） 资源需求高：占用大量CPU、内存或I/O资源 持续性：任务运行时间长或频繁执行，资源占用持续高 并发性：多任务或多线程竞争资源，放大负载
带宽：
bps： 每秒钟 最多可以传输多少个数据位 8Mbps 一秒内最多可以传输800万个比特位
超过带宽发生的问题：
延迟增加（请求排队等待发送）。 丢包（网络拥塞时被迫丢弃数据包，触发 TCP 重传）。 - > 用户感受到访问变慢（如网页加载卡顿）。如果是 DDoS 攻击（如 SYN Flood），带宽耗尽会导致正常请求无法到达。
I/O资源：
磁盘I/O（读写硬盘数据）和网络I/O（数据传输）：
对于TCP/IP协议：握手和加密涉及复杂算法 CPU需执行大量指令 每个请求触发独立协议处理，连接数多时（如Web服务器处理万级请求），CPU时间片被占满。
目前的问题： 虽然 TCP连接可以复用 但是每一次传进来的新请求 CPU都必须进行计算 如果 和很多请求传进来 CPU只需要计算一次呢？ 是不是可以节省很多CPU的资源？
在 TCP 这种面向连接的协议里，每个客户端的连接都是独立的： 每个连接 都要单独走一遍 三次握手（TCP 层）和 TLS 握手（如果是 HTTPS）。 CPU 必须为每个连接单独解析包、更新状态机、做加解密。 一个连接的解析结果不能直接拿去复用给别的连接，因为每个连接的数据内容、状态、密钥都不一样。
监听是共享的： 多个进程可以同时调用 bind() 和 listen() 绑定同一个端口（需支持 SO_REUSEPORT 选项）。 这个端口的监听请求由内核统一管理，内核维护一组监听队列，接受客户端的连接请求。 内核会把新连接均匀分配给这些监听的进程，实现负载均衡。 连接是独占的 新连接一旦被分配给某个进程，这个连接后续的所有数据包都只发给该进程对应的 socket，不会给其他监听同端口的进程。 也就是说，每条 TCP 连接只属于一个进程，不共享。
绝大多数服务进程都会同时维护多个 TCP 连接。
一个 Web 服务器进程，可能同时跟成千上万个客户端维持连接，处理请求和响应。
任务调度
CPU核心目标：
公平（每个任务都有机会执行） 高效（CPU、网络、磁盘利用率高） 响应快（对交互型任务） 吞吐量高（对批处理任务）
操作系统：
就绪队列（Ready Queue）：等待执行的任务 运行队列（Run Queue）：正在执行的任务 阻塞队列（Blocked Queue）：等待 I/O 的任务