前端计算机基础

进程和线程的区别

简单记：进程是 “独立的容器”，线程是 “容器里干活的人”，多人共享容器资源，效率更高但也更容易互相影响。

进程：独立可运行的程序，比如微信，留言及，VSCODE
进程是操作系统资源分配的最小单位（资源包括内存、CPU 时间片、文件句柄等），每个进程都有自己独立的内存空间，进程之间互不干扰。
线程：是进程的执行单位，一个进程可以包含多个县城，比如微信进程中，有接收消息线程，渲染界面线程
线程是调度执行的最小单位 ,同一进程内的线程共享进程的内存和资源。

类比：进程像一家 “独立的公司”，有自己的办公场地（内存）、资金（系统资源）；线程像公司里的 “员工”，共享公司的场地和资金，各自做不同的工作，协作完成公司整体任务。

1. 进程的使用场景

• 独立运行的程序：比如你写的一个 UniApp 打包后的 APP、一个 Python 脚本单独运行，都是一个进程。
• 需隔离资源的场景：比如服务器上的多个服务（数据库、后端接口、前端静态服务），用不同进程运行，避免一个服务崩溃影响其他服务。

2. 线程的使用场景

• 同一任务的并行处理：比如你之前写的称重代码中，串口数据接收线程、定时读取重量线程，都属于同一个 APP 进程内的线程，共享串口资源和重量数据。
• 耗时操作不阻塞主线程：比如 UniApp 中，网络请求、串口通信都要放在子线程，避免阻塞 UI 渲染线程（主线程），否则界面会卡顿。

进程间的通信

node中进程通讯分为两种：父子进程通信

​无亲缘关系进程通信

进程间通信（Inter-Process Communication，IPC）是指在操作系统中，不同进程之间交换信息和数据的过程，常见的进程通信方式包括：

• 内置 IPC 通道 //父子进程
• 管道（Pipe） //无亲缘关系进程通信
• 网络套接字（Socket） //无亲缘关系进程通信
• 文件 / 数据库（Redis 发布订阅） // 无亲缘关系进程通信

1.父子进程通信

Node.js 的 child_process 模块（尤其是 fork() 方法）内置了高效的 IPC 通道，这是实现父子进程通信最便捷的方式。

父进程

const {fork} = require("child_process");
//创建子进程
var fork1 = fork("./common/ChildIpc");

fork1.on("message", message => {
console.log(`父进程收到子进程消息:`, message);
})

fork1.send({
data: 123
})

setTimeout(()=>{
console.log("123")
},5000)

子进程
process.on("message", msg => {
console.log("收到主进程的消息", msg)
})

另外 cluster 模块， cluster 模块基于 child_process.fork() 实现，专门用于多核 CPU 利用，主进程和工作进程之间同样通过 send()/message 通信。

2.无亲缘关系进程通信

1. 管道（Pipe）

管道是操作系统提供的基础 IPC 机制，分为匿名管道（仅父子进程）和命名管道（任意进程）。Node.js 中 child_process 的 spawn/exec 方法默认会创建管道，用于标准输入 / 输出（stdin/stdout/stderr）通信。

1.匿名管道

父进程
const {spawn} = require('child_process');
var childProcessWithoutNullStreams = spawn('node', ["./common/ChildIpc.js"]);
childProcessWithoutNullStreams.stdin.write("父进程通过管道发送的数据");
childProcessWithoutNullStreams.stdin.end();

// 父进程监听子进程的 stdout 输出（子进程的回复）
childProcessWithoutNullStreams.stdout.on('data', (data) => {
console.log('父进程收到子进程回复：', data.toString());
});

setTimeout(() => {
console.log("123")
}, 5000)

子进程
process.stdin.on("data", (data) => {
console.log("收到主进程管道的消息", Buffer.from(data).toString());
process.stdout.write("反馈");
})

2.命名管道

命名管道本质是文件系统中的一个特殊文件（Linux/macOS 是 FIFO 文件，Windows 是 \\\\.\\pipe\\ 格式的管道名），不同进程可以通过读写这个 “文件” 来交换数据，它是双向通信的，且通信效率远高于网络套接字（无需走网络协议栈）。

const fs = require('fs');
const net = require('net');
const os = require('os');

// 定义跨平台的命名管道路径
const PIPE_PATH = os.platform() === 'win32'
? '\\\\\\\\.\\\\pipe\\\\my-node-pipe' // Windows 管道格式
: '/tmp/my-node-pipe'; // Linux/macOS FIFO 文件路径

// Linux/macOS 下需要先创建 FIFO 文件（Windows 无需此步骤）
function createFifoIfNeeded() {
if (os.platform() !== 'win32') {
try {
// mkfifo 命令创建 FIFO 文件，模式 0o666 表示读写权限
fs.mkfifoSync(PIPE_PATH, 0o666);
console.log(`创建 FIFO 文件: ${PIPE_PATH}`);
} catch (err) {
if (err.code === 'EEXIST') {
console.log(`FIFO 文件已存在: ${PIPE_PATH}`);
} else {
throw err;
}
}
}
}

// 启动命名管道服务端
function startPipeServer() {
createFifoIfNeeded();

// Windows 用 net.createServer 监听管道，Linux/macOS 用 fs.createReadStream/fs.createWriteStream
if (os.platform() === 'win32') {
// Windows 命名管道基于 net 模块实现
const server = net.createServer((connection) => {
console.log('客户端已连接（Windows 管道）');

// 接收客户端数据
connection.on('data', (data) => {
console.log(`收到客户端消息: ${data.toString().trim()}`);
// 回复客户端
connection.write(`服务端已收到: ${data.toString().trim()}\\n`);
});

// 监听连接关闭
connection.on('end', () => {
console.log('客户端断开连接');
});
});

// 监听命名管道
server.listen(PIPE_PATH, () => {
console.log(`Windows 命名管道服务端启动: ${PIPE_PATH}`);
});
} else {
// Linux/macOS 读取 FIFO 管道数据
const readStream = fs.createReadStream(PIPE_PATH);
readStream.setEncoding('utf8');

console.log(`Linux/macOS FIFO 服务端启动: ${PIPE_PATH}`);

// 接收客户端数据
readStream.on('data', (data) => {
const msg = data.toString().trim();
console.log(`收到客户端消息: ${msg}`);

// 回复客户端（写入同一个管道）
const writeStream = fs.createWriteStream(PIPE_PATH, { flags: 'a' });
writeStream.write(`服务端已收到: ${msg}\\n`);
writeStream.end();
});

// 监听管道关闭
readStream.on('close', () => {
console.log('FIFO 管道关闭');
});
}
}

// 启动服务端
startPipeServer();

// 优雅退出，清理资源
process.on('SIGINT', () => {
if (os.platform() !== 'win32' && fs.existsSync(PIPE_PATH)) {
fs.unlinkSync(PIPE_PATH); // 删除 Linux/macOS 下的 FIFO 文件
console.log(`已删除 FIFO 文件: ${PIPE_PATH}`);
}
process.exit(0);
});

const fs = require('fs');
const net = require('net');
const os = require('os');

// 和服务端一致的管道路径
const PIPE_PATH = os.platform() === 'win32'
? '\\\\\\\\.\\\\pipe\\\\my-node-pipe'
: '/tmp/my-node-pipe';

// 向命名管道发送消息
function sendMessage(msg) {
if (os.platform() === 'win32') {
// Windows 客户端连接管道
const client = net.connect(PIPE_PATH, () => {
console.log('已连接到 Windows 命名管道服务端');
// 发送消息
client.write(msg + '\\n');
});

// 接收服务端回复
client.on('data', (data) => {
console.log(`服务端回复: ${data.toString().trim()}`);
client.end(); // 关闭连接
});

// 处理错误
client.on('error', (err) => {
console.error('连接失败:', err.message);
});
} else {
// Linux/macOS 客户端写入 FIFO 管道
if (!fs.existsSync(PIPE_PATH)) {
console.error(`FIFO 文件不存在: ${PIPE_PATH}`);
return;
}

// 写入消息
const writeStream = fs.createWriteStream(PIPE_PATH, { flags: 'a' });
writeStream.write(msg + '\\n');
writeStream.end(() => {
console.log('客户端消息已发送');

// 读取服务端回复
const readStream = fs.createReadStream(PIPE_PATH);
readStream.setEncoding('utf8');
readStream.on('data', (data) => {
console.log(`服务端回复: ${data.toString().trim()}`);
readStream.destroy(); // 关闭读取流
});
});
}
}

// 执行客户端：node pipe-client.js "Hello Named Pipe"
const message = process.argv[2] || '默认消息：Hello Node.js 命名管道';
sendMessage(message);

2.socket

// 进程 A（服务端）
const net = require('net');
const server = net.createServer((socket) => {
console.log('有进程连接成功');

// 接收客户端数据
socket.on('data', (data) => {
console.log('服务端收到：', data.toString());
// 回复客户端
socket.write('服务端已收到消息：' + data.toString());
});
});
server.listen(3000, '127.0.0.1', () => {
console.log('TCP 服务端启动，监听 3000 端口');
});

// 进程 B（客户端）
const net = require('net');
const client = net.connect({ port: 3000, host: '127.0.0.1' }, () => {
console.log('客户端连接成功');
// 发送数据给服务端
client.write('进程 B 发送的消息');
});

// 接收服务端回复
client.on('data', (data) => {
console.log('客户端收到：', data.toString());
client.end();
});

2.共享存储 (redis发布订阅)

// 进程 1（发布者）
const { createClient } = require('redis');
const publisher = createClient(); // 默认连接本地 Redis
publisher.connect();

setInterval(async () => {
const msg = `当前时间：${new Date().toLocaleString()}`;
await publisher.publish('process-channel', msg);
console.log('发布者发送：', msg);
}, 1000);

// 进程 2（订阅者）
const { createClient } = require('redis');
const subscriber = createClient();
subscriber.connect();

subscriber.subscribe('process-channel', (msg) => {
console.log('订阅者收到：', msg);
});

线程间的通信

和进程间通信不同，Node.js 的工作线程虽然有独立的 V8 实例和内存，但支持两种通信模式：

1. 基础方式：主线程 ↔ 工作线程（消息传递）

主线程
const {Worker} = require("worker_threads")

var worker = new Worker("./common/ChildThread.js", {
workerData: {num: 1e9} // 传递给工作线程的数据
});

// 监听工作线程的消息
worker.on('message', (result) => {
console.log('工作线程计算结果:', result);
//关闭子线程
worker.terminate()
});

// 监听工作线程错误
worker.on('error', (err) => {
console.error('工作线程出错:', err);
});

// 监听工作线程退出
worker.on('exit', (code) => {
if (code !== 0) {
console.error(`工作线程退出，码值: ${code}`);
}
});

worker.postMessage({data: {num: 1e9}});

// 主线程继续执行其他逻辑
console.log('主线程不阻塞，继续执行');

子线程
parentPort.on('message', message => {
console.log("收到主线程的消息", message);

parentPort.postMessage("xxxxxxxxxxxxxx");
})

2. 进阶方式：工作线程 ↔ 工作线程（直接通信）

const {Worker} = require("worker_threads")
const thread = require("worker_threads")

var worker = new Worker("./common/ChildThread.js",);
var worker1 = new Worker("./common/ChildThread1.js",);

let {port1, port2} = new thread.MessageChannel();

// 监听工作线程的消息
worker1.on('message', (result) => {
console.log('工作线程计算结果:', result);
//关闭子线程
worker.terminate()
worker1.terminate()
});

const {parentPort} = require("worker_threads")

let worker2;

parentPort.on("message", message => {
worker2 = message.port;

worker2.on('message', (data) => {
console.log(`worker2 收到 worker1 的消息：${data}`);
parentPort.postMessage("dfdf")
});
})
let worker1;

parentPort.on('message', message => {
worker1 = message.port;
worker1.on('message', (data) => {
console.log(`worker2 收到 worker1 的消息：${data}`);
worker1.postMessage('hello worker1，我是 worker2！');
})

// 主动向 worker2 发消息
worker1.postMessage('hello worker2，我是 worker1');
})

3. 高性能方式：共享内存（SharedArrayBuffer）

通过 SharedArrayBuffer 实现线程间内存共享，数据无需复制，适合大数据量传输（如实时计算、数据共享），但需要注意并发安全。

// main.js
const { Worker } = require('worker_threads');

// 创建共享内存（单位：字节，这里分配 4 字节存整数）
const sharedBuffer = new SharedArrayBuffer(4);
// 用 Uint32Array 包装共享内存，方便操作
const sharedArray = new Uint32Array(sharedBuffer);

// 初始化值为 0
sharedArray[0] = 0;

// 创建两个工作线程，共享同一块内存
const worker1 = new Worker('./worker-shared.js', {
workerData: { sharedBuffer, id: 1 }
});
const worker2 = new Worker('./worker-shared.js', {
workerData: { sharedBuffer, id: 2 }
});

// 监听线程退出，打印最终结果
setTimeout(() => {
console.log(`共享内存最终值：${sharedArray[0]}`);
worker1.terminate();
worker2.terminate();
}, 1000);

// worker-shared.js
const { workerData } = require('worker_threads');
const { sharedBuffer, id } = workerData;

// 包装共享内存
const sharedArray = new Uint32Array(sharedBuffer);

// 两个线程同时累加 1000 次（模拟并发）
for (let i = 0; i < 1000; i++) {
// 使用 Atomics 保证原子操作，避免竞态问题
Atomics.add(sharedArray, 0, 1);
}

console.log(`线程 ${id} 累加完成`);

单核CPU如何实现并发

单核CPU 主要是通过时间片轮转和上下文切换来实现并发

时间片轮转

• CPU将时间划分为很小的时间片，通常是几十毫秒
• 每个进程、线程分配到一个时间片
• CPU轮流执行每个进程、线程的时间片
• 当一个时间片用完，CPU就会切换到下一个进程、线程

上下文切换

• 在切换进程、线程时，CPU需要保存当前进程的状态（上下文），包括
  • 程序计数器的值
  • 寄存器的值
  • 内存映射信息
• 加载下一个要执行的进程、线程的上下文

在任意时刻，CPU只能执行一个任务，由于切换速度非常快，给用户的感觉就像是在同时运行多个程序，所以这种机制被称为“伪并发”，若线程过多也不好，频繁的上下文切换会带来一定的性能开销，所以过多的线程反而会带来性能下降的问题

CPU 调度算法有哪些？

• 先来先服务（First Come First Serve）
  • 最简单的调度算法
  • 进程按到达的顺序排队，先到达的先执行
  • 缺点：可能导致长时间的等待，特别是当一个长进程在队列前面时
• 短作业优先（Shortest Job First）
  • 优先执行预计运行时间最短的进程
  • 可以是非抢占式或是抢占式（shortest Remaining Time First，SRTF）
  • 可能导致“饥饿”现象，即长作业可能永远得不到执行
• 优先级调度（Priority Scheduling）
  • 每个进程分配一个优先级，优先级高的进程先执行
  • 也可能导致“饥饿”现象，通常使用老化（aging）技术来解决
• 轮转调度（Round Robin）
  • 每个进程分配一个固定的时间片，时间片用完后，进程被放到队列的末尾
  • 适用于时间共享系统
  • 时间片的大小对系统性能有很大影响
• 多级队列调度（Multilevel Queue Scheduling）
  • 将进程分成多个队列，每个队列有不同的优先级
  • 不同队列可以使用不同的调度算法
• 多级反馈队列调度（Multilevel Feedback Queue）
  • 允许进程在不同的队列之间移动
  • 根据进程的行为动态调整其优先级

linux 如何查找你的进程占用的那个端口

# 查看所有端口占用情况
netstat -tunlp
# 查看特定端口，比如 8080
netstat -tunlp | grep 8080

返回pid

# TCP 端口
fuser 8080/tcp
# UDP 端口
fuser 8080/udp

结束占用

kill 805

什么是编译型语言和解释型语言，他们有什么区别？

可以把编程语言的执行过程想象成 “看书”：

• 编译型语言：就像先请翻译把整本外文书翻译成中文书，你之后直接看翻译好的中文书就行。程序运行前，会通过编译器将源代码一次性翻译成机器能直接执行的二进制指令（可执行文件），后续运行时不再需要源代码。
• 解释型语言：就像请翻译逐句给你解释外文书，你看一句，翻译解释一句。程序运行时，由解释器逐行读取源代码、逐行解释执行，不会生成独立的二进制可执行文件。

编译型语言和解释型语言的区别

• 执行速度：编译型语言通常比解释型语言快，因为他们直接运行机器码
• 开发灵活性：解释型语言通常更灵活，适合快速开发和迭代
• 错误检测：编译型语言在编译阶就可以捕获更多的语法和类型错误，而解释型语言通常在运行时才发现错误

JIT（Just-In-Time）编译

为了结合编译型和解释型语言的优点，JIT 随之诞生，可以理解为“即时编译”

• 执行方式：JIT 编译在程序运行时将部分代码编译成机器码，而不是逐行解释，这种编译方式在代码即将被执行时进行，因此得名“即时编译”
• 应用场景：现代 JavaScript 引擎（如 V8 引擎）通常使用 JIT 编译来提高性能，包括 Java 虚拟机（JVM）也会使用 JIT 编译来提高性能

栈与堆

在 JavaScript 中，所有变量和数据都会被存储在内存中，而栈和堆是两种不同的内存分配区域，分工明确：

• 栈（Stack）：类似 “叠盘子”，遵循「先进后出（LIFO）」原则，存储占用空间固定、大小已知的数据，访问速度极快。
• 堆（Heap）：类似 “开放式仓库”，存储占用空间不固定、大小动态变化的数据，访问速度相对慢，但灵活性高。

1. 栈（Stack）—— 存储基础类型 + 引用类型的指针

JavaScript 的基本数据类型会直接存在栈中：

• 基本类型：Number、String、Boolean、Undefined、Null、Symbol、BigInt
• 特点：占用空间小且固定，赋值时会复制整个值（值传递）。

此外，函数调用的执行上下文（比如函数的参数、局部变量、执行状态）也会存在栈中，函数执行完后会被立即弹出栈，释放内存。

// 基本类型存储在栈中
let a = 10;
let b = a; // 复制栈中的值，a和b是两个独立的变量
b = 20;
console.log(a); // 输出 10（a不受b修改影响）
console.log(b); // 输出 20

2. 堆（Heap）—— 存储引用类型

JavaScript 的引用类型会存储在堆中，栈中仅保存指向堆内存的「指针（地址）」：

• 引用类型：Object（包括数组、对象、函数、正则等）
• 特点：占用空间大且动态变化，赋值时仅复制指针（引用传递），多个变量可能指向堆中同一个数据。

// 引用类型存储在堆中，栈中存地址
let obj1 = { name: "张三" };
let obj2 = obj1; // 复制栈中的地址，obj1和obj2指向堆中同一个对象
obj2.name = "李四";
console.log(obj1.name); // 输出 李四（修改obj2会影响obj1）
console.log(obj2.name); // 输出 李四

// 验证地址指向：修改obj2的引用不会影响obj1
obj2 = { name: "王五" }; // 栈中obj2的地址指向新的堆内存
console.log(obj1.name); // 输出 李四（obj1仍指向原地址）
console.log(obj2.name); // 输出 王五

• 栈内存：函数执行上下文出栈时，对应的变量会被立即释放，无需垃圾回收。
• 堆内存：当一个对象不再被任何变量（栈中的指针）引用时，垃圾回收器会在合适时机清理这块内存，避免内存泄漏。

简述 JS 垃圾回收的过程。用什么算法？

首先，我们可以用一个通俗的比喻来理解：JS 引擎就像一个管家，内存是家里的储物空间。当你创建变量、对象、函数时，管家会分配空间存放；垃圾回收 就是管家定期清理那些你再也用不到的 “杂物”（不再被引用的内存），释放空间避免堆积。

核心原则：找出不再使用的变量 / 对象，释放其占用的内存。

二、JS 垃圾回收的主要算法

JS 引擎（如 V8）主要使用两种核心算法，且会根据数据大小 / 类型选择不同策略：

1. 引用计数法（早期算法，有缺陷）

• 原理

  ：跟踪每个值被引用的次数。

  • 当一个值被创建并赋值给变量时，引用数 = 1；
  • 若该值被其他变量引用，引用数 +1；
  • 若引用它的变量被覆盖 / 销毁，引用数 -1；
  • 当引用数变为 0 时，说明该值无法被访问，会被回收。

• 缺陷：无法解决 循环引用 问题（比如两个对象互相引用，即使都不再被外部使用，引用数也永远不为 0）。

function fn() {
let obj1 = {};
let obj2 = {};
obj1.a = obj2; // obj1 引用 obj2
obj2.b = obj1; // obj2 引用 obj1
}
fn(); // 函数执行完后，obj1/obj2 本应被回收，但循环引用导致引用数不为 0

2. 标记清除法（现代 JS 引擎主流算法）

这是目前 Chrome/V8、Node.js 等环境的核心算法，解决了循环引用问题。

• 原理

  （分两步）：

• 标记阶段：从根对象（全局对象 window/global、执行栈中的变量等）出发，遍历所有可访问的对象，给这些 “可达” 的对象打上标记；
• 清除阶段：清理所有未被标记的对象（即 “不可达” 的对象），释放其内存。

• 优势：即使对象循环引用，只要它们无法从根对象访问到，就会被标记为垃圾并清除。

function fn() {
let obj1 = {};
let obj2 = {};
obj1.a = obj2;
obj2.b = obj1;
}
fn();
// 函数执行完后，obj1/obj2 从根对象（全局）无法访问，会被标记为垃圾并清除

3. 分代回收（V8 优化策略）

V8 把内存分为两类，针对不同特点优化回收效率：

• 新生代（Young Generation）：存放短期存活的对象（如临时变量），空间小（几 MB），回收频率高，采用 Scavenge 算法（将内存分为 From/To 两个区域，复制存活对象到 To 区，清空 From 区，然后交换两区角色）；
• 老生代（Old Generation）：存放长期存活的对象（如全局变量），空间大，回收频率低，主要用 标记 – 清除 + 标记 – 整理 算法（标记清除后，会整理内存碎片，避免内存不连续）。

闭包为什么不会被销毁

JavaScript 有自动垃圾回收机制，它的核心判断逻辑是：如果一个对象 / 变量没有任何可达的引用（即 “无人使用”），就会被标记为可回收，最终销毁并释放内存。

闭包不会被销毁，本质是打破了这个规则 —— 闭包让内部函数保留了对外部函数作用域的引用，导致外部函数的作用域始终有 “可达引用”，因此不会被回收。

function outer() {
// 外部函数的变量
let count = 0;

// 内部函数（闭包）：引用了外部的count
function inner() {
count++;
console.log(count);
}

// 返回内部函数，让外部能访问到inner
return inner;
}

// 执行outer，得到inner函数，并赋值给变量fn
const fn = outer();

// 调用fn，依然能访问到count
fn(); // 输出 1
fn(); // 输出 2

不是所有闭包都不会销毁：如果闭包没有被外部引用（比如内部函数只在外部函数内部调用，没有返回 / 赋值给外部变量），那么外部函数执行完后，闭包和对应的作用域会被正常回收。

闭包不销毁≠内存泄漏：合理使用闭包（比如用完后手动切断引用）不会造成内存泄漏；只有滥用闭包（比如长期保留不必要的闭包引用）才会导致内存占用过高。

什么是内存泄漏？如何排查？JS 内存泄漏的常见原因？

内存泄露是指在程序运行过程中，程序未能释放不再使用的内存空间，导致内存资源被浪费。

排查内存泄露

JS 内存泄露的常见原因

冯·诺依曼架构是什么？

冯·诺依曼架构确定了现代计算机结构中的五大部件：

计算机内部为何使用二进制？

• 硬件实现简单：二进制只需要两个状态，通常用电压的高低来表示（如高电压表示 1，低电压表示 0）。这种简单的状态切换使得硬件电路设计更为简单和可靠
• 抗干扰能力强：在电路中，二进制的两个状态（0 和 1）可以通过明显的电压差来区分，这使得系统对噪声和干扰的容忍度更高，数据传输更稳定
• 逻辑运算方便：计算机的基本运算是逻辑运算，二进制系统与布尔代数非常契合，能够进行与，或，非等逻辑运算，简化了计算机的设计和操作
• 存储和处理效率高：二进制数据在计算机中可以直接存储和处理，避免了其他进制系统转换带来的复杂性和效率损失
• 历史和标准化：从计算机发展的早期，二进制就被广泛采用，形成了标准化的设计和技术积累，进一步推动了其普及和应用

什么是虚拟内存，为何要使用虚拟内存？

虚拟内存是操作系统搞出来的一个 “假内存” 机制：

• 让每个程序都以为自己独占一大片连续的内存地址（虚拟地址）
• 实际物理内存（内存条）很小，系统会把这些 “虚拟地址”映射到真实的物理内存或硬盘上
• 程序只管使用虚拟地址，不用关心数据到底在内存还是硬盘

简单说：

虚拟内存 = 程序看到的地址空间

物理内存 = 真正的内存条

为什么要用虚拟内存？（核心 4 点）

什么是 Unicode 编码？它和常见的 UTF-8 有什么关系？

• Unicode 俗称万国码，它为每个字符提供了一个唯一的数字标识，这个数字标识被称为码点。Unicode 的出现就是为了解决 ASCII 编码的局限性，ASCII 编码只能表示 128 个字符，全球各个国家的字符远不止 128 个，所以 Unicode 应运而生。

• Unicode 的定义了一个字符集和一系列编码方案（UTF-8，UTF-16，UTF-32），UTF-8 是 Unicode 最常用的编码方案，它是一种变长编码，根据不同的字符，使用不同的字节数来表示。对于 ASCII 字符，使用 1 个字节表示，与 ASCII 编码兼容

• GBK 编码是一种用于中文字符的编码标准，扩展了 GB2312 编码，支持简体和繁体中文字符。GBK 编码使用 2 个字节表示一个中文字符，适合中文环境，但不支持 Unicode

简述计算机网络的 OSI 模型

1. 应用层（Application Layer）

为应用程序提供网络服务接口。

协议：HTTP、HTTPS、FTP、SMTP、DNS

2. 表示层（Presentation Layer）

负责数据格式转换、加密、解密、压缩、解压缩。

3. 会话层（Session Layer）

建立、管理、终止应用之间的会话连接。

4. 传输层（Transport Layer）

负责端到端的数据传输、流量控制、差错重传。

协议：TCP、UDP

数据单元：段（Segment）

5. 网络层（Network Layer）

负责寻址、路由选择，将数据从源送到目标。

协议：IP、ICMP、ARP

数据单元：包（Packet）

6. 数据链路层（Data Link Layer）

将物理层收到的信号组成帧，进行差错检测。

设备：交换机、网卡

数据单元：帧（Frame）

7. 物理层（Physical Layer）

传输比特流，定义电气、物理接口标准。

设备：集线器、中继器、网线、光纤

数据单元：比特（Bit）

一个域名对应一个 ip 吗

1. 一个域名 → 多个 IP

很常见，目的：负载均衡、高可用、就近访问

• 比如：baidu.com 会解析到一堆 IP
• 你访问时，DNS 会返回其中一个
• 多用于大型网站、CDN、云服务

2. 一个 IP → 多个域名

更常见，叫虚拟主机 / 共享主机

• 一台服务器一个 IP，但上面跑几十个网站
• 浏览器请求时会带上 Host 头，服务器知道你要访问哪个站

简单记

• 域名 → IP：可以一对多（负载均衡）
• IP → 域名：可以多对一（共享服务器）

只有极少数场景才是严格一对一：

• 独立服务器、单独备案、独享 IP 的站点等。

UDP 和 TCP和HTTP 协议的区别？有什么应用场景

1. 三者本质关系

• TCP/UDP：传输层协议，负责数据怎么传。
• HTTP：应用层协议，基于 TCP，负责数据是什么、要干嘛。

一句话：

HTTP 跑在 TCP 之上，TCP 和 UDP 是平级的传输协议。

2. TCP vs UDP 核心区别

TCP（传输控制协议）

• 可靠：有确认、重传、有序、不丢包
• 面向连接：先三次握手建立连接
• 有拥塞控制
• 速度慢、开销大

UDP（用户数据报协议）

• 不可靠：发出去就不管，可能丢包、乱序
• 无连接：直接发，不用握手
• 速度极快、开销小

3. HTTP 是什么

• 应用层协议，基于 TCP
• 定义了：请求方法（GET/POST）、头、状态码、报文格式
• 是一问一答模式：客户端请求 → 服务器响应

4. 最直观对比表

5. 应用场景（最实用部分）

TCP 场景（要求不丢、不错、不乱）

• 网页浏览（HTTP/HTTPS）
• 文件传输（FTP、HTTP 下载）
• 邮件（SMTP、POP3）
• 登录、支付、接口请求

UDP 场景（要求快、实时，丢一点没关系）

• 直播、实时音视频（抖音、微信通话）
• 游戏（王者荣耀、吃鸡）
• DNS 查询
• IoT 设备上报、实时监控

HTTP 场景（业务接口、网页、API）

• 网站、H5、小程序请求
• RESTful API、后端接口交互
• 文件上传 / 下载
• 登录、支付、查询等必须可靠的业务