问2：磁盘坏了吗？
磁盘坏了 → 介质故障
磁盘没坏 → 排除介质故障
问3：是单个事务出错，还是整个系统停摆？
单个事务 → 事务故障
整个系统停了 → 系统故障
具体案例判断思路
案例1：服务器突然断电
内存数据丢失 → 系统故障
磁盘没坏 → 不是介质故障
重启后需要 REDO+UNDO
✅ 系统故障
案例2：磁盘磁头损坏，数据读不出来
存储介质物理损坏 → 介质故障
内存数据可能还在（如果事务没提交，内存可能没影响） → 不是系统故障（系统没崩）
✅ 介质故障
案例3：某个事务执行时除0，被系统强制终止
单个事务出错 → 事务故障
内存数据还在 → 不是系统故障
磁盘没坏 → 不是介质故障
只需要 UNDO 这个事务
✅ 事务故障
案例4：数据库在写入日志时突然停电
内存数据丢失 → 系统故障
日志文件可能部分写入磁盘，恢复时要用日志做 REDO/UNDO
✅ 系统故障
断电 → 选 系统故障（除非题目说磁盘也坏了）
死锁 → 选 事务故障（虽然死锁由系统解决，但对事务来说是故障）
磁盘坏道 → 选 介质故障
系统崩溃 → 选 系统故障
断点和断电，甭管是不是写错的都是系统故障
各个功能模块用不同语言编写 → 分别编译成目标模块（.obj / .o 文件）。
目标模块还不能直接运行，需要链接（Link）成可执行文件。
链接主要完成：符号解析、地址重定位、模块合并等。
LIKE '王%' → 第一个字是“王”，后面任意字符
LIKE '%王%' → 只要名字中包含“王”字，不管在什么位置
正负0的补码是相同的，正负0的移码是相同的
攻击者（称为“钓鱼者”）会伪装成你信任的人或机构（比如银行、电商平台、同事、政府机构等），通过发送虚假邮件、短信或创建假冒网站，诱导你交出敏感信息（如账号密码、身份证号、信用卡号）或在你的设备上安装恶意软件。
阻塞→运行，是不被允许的
因为现代操作系统为了让系统更稳定、更安全，会把每个进程隔离在各自独立的内存空间里——就像一个房间只住一个人，他们不能直接看到对方屋里的东西。但有时候进程之间又需要协作（比如浏览器进程要把下载的数据交给播放器进程去播放），这时候就需要 IPC 来帮忙“传话”或“递东西”。
就是进程间的电话或者传声筒
根据场景不同（是要传少量控制信息，还是要传大批量数据，或者只是想同步一下动作），IPC 有几种主流实现方式：
- 管道（Pipe）
是什么：一种半双工（单向）的数据流，像一个水管，一头接进程 A，一头接进程 B。
场景：最典型的就是命令行里的 | 符号。比如 ps aux | grep nginx，就是把 ps 进程的输出接到 grep 进程的输入里。
特点：简单，通常用于有亲缘关系的进程（比如父子进程）。 - 消息队列（Message Queue）
是什么：进程可以把数据封装成一个“消息”（有类型、有内容），扔到一个队列里，另一个进程再从队列里取。
场景：适用于需要异步通信的场景，比如服务器接收客户端的请求，先放进队列，慢慢处理。
特点：解耦，消息有边界，不会像管道那样只是字节流。 - 共享内存（Shared Memory）
是什么：划出一块内存区域，让多个进程都能直接读写。这是速度最快的 IPC，因为没有数据复制的开销。
场景：需要大量数据交换的时候，比如视频渲染、数据库缓存。
特点：快，但需要配合信号量之类的同步机制使用，否则多个进程同时写会乱套。 - 信号（Signal）
是什么：一种异步通知机制，一个进程可以给另一个进程发一个简单的“信号”，告诉它发生了某件事（比如 Ctrl+C 就是发 SIGINT 信号）。
场景：用于事件通知、异常处理、进程控制。
特点：携带信息量很少，只能发个编号，不能传大量数据。 - 套接字（Socket）
是什么：本来设计用于网络通信，但也可以在同一台机器的不同进程间通信（Unix Domain Socket）。
场景：最通用的 IPC，特别是跨网络的进程通信，比如 Web 服务器和浏览器之间。
特点：支持双向通信，可用于不同机器，但开销比共享内存大。 - 信号量（Semaphore）
是什么：本质上是一个计数器，用于进程间同步，而不是直接传数据。用来协调多个进程对共享资源的访问。
场景：配合共享内存使用，防止竞争条件。
特点：只用来同步，不传数据。
- 阻塞型同步原语
互斥锁（阻塞版本）：例如 pthread_mutex_lock 的默认行为。如果锁已被占用，线程会挂起（进入睡眠），不消耗CPU，直到锁被释放后由内核调度唤醒。
信号量（阻塞版本）：当信号量计数值为0时，执行 P 操作的进程会阻塞，加入等待队列，不会轮询。
条件变量：pthread_cond_wait 会将线程阻塞，并释放已持有的互斥锁。当条件满足时，通过 pthread_cond_signal 唤醒线程。整个过程没有忙等待。
读写锁（阻塞版本）：类似互斥锁，读/写锁冲突时，线程阻塞。
- 事件/通知机制
事件对象（如Windows的Event、Linux的eventfd）：线程可以等待一个事件变为有信号状态，等待期间线程挂起。
信号（Signal）：进程可以注册信号处理函数，并调用 pause() 或 sigsuspend() 挂起，信号到来时自动唤醒。
消息队列：接收者尝试从空队列中取消息时，可以选择阻塞直到有消息到达。
Future/Promise 或异步模型：在协程或异步编程中，任务可以挂起（yield），不阻塞线程，但本质上也不是忙等待。
- I/O 操作的阻塞模式
阻塞I/O：当进程调用 read() 从网卡或磁盘读取数据而数据未准备好时，进程会进入睡眠状态，由内核在数据到达后唤醒它。
多路复用（如 select/poll/epoll）：这些调用本身可以阻塞，直到监控的某个文件描述符就绪。调用者阻塞在内核中，不忙等待。
- 硬件中断
中断驱动：CPU在等待外部设备完成操作时，可以执行其他任务。设备完成后通过硬件中断通知CPU，CPU暂停当前任务去处理中断。这种方式完全避免了忙等待。
它展示系统中有哪些“东西”（对象、类），以及这些东西之间是什么关系（继承、关联等）。你提到的“静态设计视图”就是指它关注的是结构，而不是动作。
序列图：画的是某一个具体流程的细节。
它展示多个对象之间为了完成一个功能（比如用户登录），是按什么时间顺序来互相发消息的。你提到的“对象生命线”、“控制焦点”都是用来描述这个时间顺序的符号。
部署图：画的是软件跑在什么硬件上。
它展示最终写好的程序（构件）要安装在哪台服务器上（运行处理节点），服务器之间怎么连接。这是物理层面的视图。
状态图：画的是某一个东西的“一生”。
它专门盯着某一个对象（比如一个订单），看它从创建到最后销毁，会经历哪些状态（待支付、已支付、已发货），以及在什么事件（用户点击支付）的触发下发生状态转换。
为什么要把它们统称为 UML？
UML 本身不是一个工具，而是一套标准。它把软件工程历史上各种优秀的建模方法（比如 Booch 方法、OMT 方法、OOSE 方法）统一起来，形成了我们现在看到的这 14 种（最初是 9 种）标准图。
你列出的这四张图，覆盖了 UML 的两大分类：
结构图（描述静态构成）：类图、部署图属于这一类。
行为图（描述动态交互）：序列图、状态图属于这一类。
评论 (0)