无敌岩雀的博客

责链模式应用的一个请求可能有多个接收者（扮演处理者角色），但最后只有一个接收者会处理该请求。此时，请求的发送者和接收者之间是解耦的。换句话说，请求的发送者只需要将请求发送到链上，并不关心请求的处理细节以及请求的传递，也并不知道最终会被哪个接收者处理，这种灵活性可以更好地应对变化。

代理模式的使用方式有很多，延迟初始化 （虚拟代理）。如果有一个偶尔使用的重量级服务对象， 一直保持该对象运行会消耗系统资源时， 可使用代理模式。无需在程序启动时就创建该对象， 可将对象的初始化延迟到真正有需要的时候。访问控制：如果你只希望特定客户端使用服务对象， 这里的对象可以是操作系统中非常重要的部分， 而客户端则是各种已启动的程序 （包括恶意程序）， 此时可使用代理模式。代理可仅在客户端凭据满足要求时将请求传递给服务对象。代理模式和装饰模式有类似之处，但是这两个模式要解决的问题不同或者说立场不同。

享元对象最重要的就是对“内部状态”和“外部状态”做出了明确的区分，这是享元对象能够被共享的关键所在。内部状态：存储在享元对象内部的，一直不会发生改变的状态，这种状态可以被共享。例如，对于BlackPiece类对象，它的内部状态就是黑棋子，它一直代表黑棋子，不会发生改变。而对于WhitePiece类对象，它的内部状态就是白棋子，它一直代表白棋子，不会发生改变。内部状态一般可以作为享元类的成员变量而存在。外部状态：随着着外部环境和各种动作因素的改变而发生改变的状态，这种状态不可以被共享。

外观模式定义一组高层接口或者说提供子系统的一个到多个简化接口让子系统更容易使用以及让操作变得更直接，让客户端和子系统实现解耦。当子系统发生改变时，一般只需要修改外观类而基本不需要修改客户端代码（虽然这种修改有点违背开闭原则）。外观模式提供的接口给客户端调用带来了很大的方便，使客户端无须关心子系统的工作细节，但这些接口也许缺乏灵活性，当然，如果客户端认为有必要对子系统进行最灵活的控制，那么依然可以绕过外观模式类而直接使用子系统。

装饰模式是一种结构型设计模式， 允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。该模式展现出了运行时的一种扩展能力，以及比继承更强大和灵活的设计视角和设计能力，甚至在有些场合下，不使用该模式很难解决问题。

引人组合设计模式的定义：将一组对象（如文件和目录）组织成树形结构以表示“部分-整体”的层次结构（如目录中包含文件和子目录）。使得用户对单个对象（文件）和组合对象（目录）的操作/使用/处理（递归遍历并执行`ShowName`逻辑等）具有一致性。

桥接（Bridge）模式也叫桥梁模式，简称桥模式，是一种结构型模式。该模式所解决的问题非常简单，即根据单一职责原则，在一个类中，不要做太多事，如果事情很多，尽量拆分到多个类中去，然后在一个类中包含指向另外一个类对象的指针，当需要执行另外一个类中的动作时，用指针直接去调用另外一个类的成员函数。

适配器模式在软件开发中使用得比较广泛，但并不是总是最佳选择。过多地使用适配器模式可能会导致混淆，因为从外部看调用的是 A 接口，但内部却适配成了 B 接口。这种情况在项目后期重构时通常更常见，因此在可能的情况下，重构代码可能比使用适配器更好。然而，在软件开发中，发布新版本时常常会面临与旧版本的兼容性问题。完全抛弃旧版本并不现实，因此适配器模式可以帮助实现新旧版本的兼容。尤其在遗留代码的复用和类库迁移等方面，适配器模式发挥了重要作用。

原型模式与工厂方法模式在创建对象时的主要区别在于它们如何处理对象的创建过程和状态复制。原型模式通过复制现有对象（原型）来创建新对象，新对象的初始状态与原型对象相同，这避免了复杂的设置过程。当对象的内部数据复杂且多变时，原型模式比工厂方法模式更合适，因为它可以直接克隆当前状态，无需额外的设置代码。例如，在游戏中创建一个具有特定状态的怪物分身，使用原型模式可以快速复制这些状态。工厂方法模式和原型模式在创建对象时都不需要知道具体的类名，但它们的工作方式不同。

相较于工厂模式，生成器模式同样用于对象的生成，但更侧重于构造细节，增加了额外的构建流程，以便处理复杂对象的构建需求。生成器模式也是一种创建型设计模式， 使我们能够分步骤创建复杂对象。 该模式允许使用相同的创建代码生成不同类型和形式的对象。 也就是说，生成器模式就是为了生成一个复杂的对象。

简单工厂、工厂方法和抽象工厂是三种常见的创建型设计模式，它们各自有不同的特点和应用场景。代码实现复杂度上，简单工厂模式最简单，工厂方法模式次之，抽象工厂模式最复杂。简单工厂模式中的代码修改得符合开闭原则，就变成了工厂方法模式，修改工厂方法模式的代码使一个工厂支持对多个具体产品的生产，就变成了抽象工厂模式。从需要的工厂数量上。

懒汉式单例适用于需要延迟加载实例的场景，但在多线程环境下需要加锁。饿汉式单例简单且不需要考虑线程安全，但在不需要时也会占用内存。C++11静态局部变量单例实现方式最为简洁，并且在多线程环境下是安全的，是推荐使用的方法。懒汉模式的缺点是在创建实例对象的时候有安全问题，但这样可以减少内存的浪费（如果用不到就不去申请内存了）。饿汉模式则相反，在我们不需要这个实例对象的时候，它已经被创建出来，占用了一块内存。对于现在的计算机而言，内存容量都是足够大的，这个缺陷可以被无视。

Git 是当今软件开发中不可或缺的版本控制工具，无论是个人项目还是团队协作，它都能够帮助开发者轻松地管理代码变更，追踪历史记录，提升开发效率。本篇博客将带你深入了解 Git 的核心原理，从 .git 目录的内部结构到常见的版本回退和修改撤销操作。此外，还会详细介绍如何与远程仓库进行交互，包含克隆、推送、拉取操作，以及标签的管理方法。分支操作也是 Git 的重要部分，本博客也将对其进行详细剖析，帮助你掌握分支管理策略以及如何在实际开发中高效利用分支来处理 bug 修复和功能开发。

即把第一次通过ARP获取到的MAC地址作为IP对MAC的映射关系记忆到一个ARP缓存表中，下一次再向这个IP地址发送数据报时不需再重新发送ARP请求，而是直接使用这个缓存表当中的MAC地址进行数据报的发送。也就是说，这个ARP请求包包括了主机B的IP地址。：若UDP携带的数据超过1472（1500-20（IP首部）-8（UDP首部）），那么就会在网络层分成多个IP数据报，任何一个IP数据报丢失，都会引起接收端网络重组失败，那么就意味着，如果 UDP 数据报在网络层被分片，整个数据被丢失的概率就大大增加了。

当某个IP包到达路由器时，路由器首先查找其目标地址（IP包被转发到途中的某个路由器时，实际上是装入数据链路层的数据帧以后再被送出），从而再决定下一步应该这个数据包到达哪个路由器，然后再把包发送过去。因此，IP 层进行分片传输是很没有效率的。在进行 NAT 转换时，路由器会将源 IP 地址和端口号替换为它自己的公网 IP 地址+端口号，并在其 NAPT 转换表中记录转换信息，以便在接收到响应数据包时，能够将目标 IP 地址从公网 IP 地址转换为对应的私有 IP 地址，并将响应数据包发送回相应的局域网主机。

TCP 旨在构建在 IP 层之上的一种稳定的数据传输服务。IP层虽然能够将数据包从一端传输到另一端，但其服务性质是尽力而为，不保证数据的可靠到达。TCP的设计目标是在这样的基础上，提供一种确保数据完整性和顺序性的传输机制。也就是说，TCP 提供可靠数据传输服务保证接收方进程从缓冲区读出的字节数与发送方发出的字节流完全一样。TCP 使用了校验、序号、确认和重传等机制来达到这一目的。

TCP与UDP的区别相当大。它充分地实现了数据传输时各种控制功能，可以进行丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些在UDP中都没有。此外，TCP作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费（由于UDP没有连接控制，所以即使对端从一开始就不存在或中途退出网络，数据包还是能够发送出去。（当ICMP错误返回时，有时也实现了不再发送的机制。）） 。根据TCP的这些机制，在IP这种无连接的网络上也能够实现高可靠性的通信。

在使用UDP的情况下，虽然可以确保发送消息的大小（例如，发送端应用程序发送一个100字节的消息，那么接收端应用程序也会以100字节为长度接收数据。这样，在进程能够读该套接字中任何已排好队的数据报之前，如果有多个数据到达该套接字，那么相继到达的数据报仅仅加到该套接字的接收缓冲区中。在UDP中，每个数据报文（数据报）都是独立的，不依赖于前后的数据报。：由UDP给某个特定套接字排队的UDP数据报的数目受限于该套接字接收缓冲区的大小，但是这个缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致。

在TCP/IP协议中，传输层有两个重要的协议：TCP和UDP。TCP用于提供可靠的数据传输，而UDP则适合用于广播或对细节控制要求不高的应用传输。为了确保传输层协议能够正确地将接收到的数据交给相应的应用程序，TCP和UDP都引入了的概念，用来识别目标应用。

hrbnu操作系统复习大纲