跳到主要内容前端计算机基础 | 极客日志JavaScriptNode.js大前端算法
前端计算机基础
综述由AI生成涵盖前端计算机基础核心知识,包括进程与线程的区别、进程间通信(IPC)方式(如 Node.js 父子进程、管道、Socket、Redis)、线程间通信(Worker Threads、共享内存)。此外还讲解了单核 CPU 并发原理、CPU 调度算法、Linux 端口查找、编译型与解释型语言区别、JS 内存管理(栈堆、垃圾回收机制、闭包、内存泄漏)、冯·诺依曼架构、二进制优势、虚拟内存、字符编码(Unicode/UTF-8)、OSI 网络模型以及 TCP/UDP/HTTP 协议对比。内容结合 Node.js 实例,适合前端开发者夯实底层基础。
猫巷少女32 浏览 进程和线程的区别
简单记:进程是'独立的容器',线程是'容器里干活的人',多人共享容器资源,效率更高但也更容易互相影响。
进程:独立可运行的程序,比如微信、留言及、VSCode。进程是操作系统资源分配的最小单位(资源包括内存、CPU 时间片、文件句柄等),每个进程都有自己独立的内存空间,进程之间互不干扰。
线程:是进程的执行单位,一个进程可以包含多个线程,比如微信进程中,有接收消息线程、渲染界面线程。线程是调度执行的最小单位,同一进程内的线程共享进程的内存和资源。
类比:进程像一家'独立的公司',有自己的办公场地(内存)、资金(系统资源);线程像公司里的'员工',共享公司的场地和资金,各自做不同的工作,协作完成公司整体任务。
| 维度 | 进程 | 线程 |
|---|
| 资源分配 | 系统资源分配的最小单位 | 资源调度 / 执行的最小单位 |
| 内存空间 | 每个进程有独立的内存空间 | 共享所属进程的内存空间 |
| 通信方式 | 复杂(需 IPC:管道、套接字、共享内存等) | 简单(直接读写进程内共享变量) |
| 创建 / 销毁开销 | 大(需分配独立内存、资源) | 小(仅需栈空间,共享进程资源) |
| 独立性 | 高(进程崩溃不影响其他进程) | 低(线程崩溃可能导致整个进程崩溃) |
| 切换开销 | 大(需切换地址空间、资源上下文) | 小(仅切换执行上下文) |
| 控制权 | 由操作系统内核管理 | 可由进程自己管理(用户级线程)或内核管理 |
1. 进程的使用场景
- 独立运行的程序:比如你写的一个 UniApp 打包后的 APP、一个 Python 脚本单独运行,都是一个进程。
- 需隔离资源的场景:比如服务器上的多个服务(数据库、后端接口、前端静态服务),用不同进程运行,避免一个服务崩溃影响其他服务。
2. 线程的使用场景
- 同一任务的并行处理:比如你之前写的称重代码中,串口数据接收线程、定时读取重量线程,都属于同一个 APP 进程内的线程,共享串口资源和重量数据。
- 耗时操作不阻塞主线程:比如 UniApp 中,网络请求、串口通信都要放在子线程,避免阻塞 UI 渲染线程(主线程),否则界面会卡顿。
进程间的通信
Node.js 中进程通讯分为两种:父子进程通信、无亲缘关系进程通信。
进程间通信(Inter-Process Communication,IPC)是指在操作系统中,不同进程之间交换信息和数据的过程,常见的进程通信方式包括:
- 内置 IPC 通道 // 父子进程
- 管道(Pipe) // 无亲缘关系进程通信
- 网络套接字(Socket) // 无亲缘关系进程通信
- 文件 / 数据库(Redis 发布订阅) // 无亲缘关系进程通信
| 方式 | 适用场景 | 优点 | 缺点 |
|---|
| 内置 IPC 通道 | 父子进程(Node.js 间) | 高效、原生、使用简单 | 仅父子进程、不跨机器 |
| 管道 | 父子进程 / 本地进程 | 轻量、系统原生 | 仅本地、单向 / 半双工 |
| TCP Socket | 任意进程(跨机器 / 跨语言) | 通用、跨平台、实时性好 | 有网络开销、需处理连接 |
|
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();
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' : '/tmp/my-node-pipe';
function createFifoIfNeeded() {
if (os.platform() !== 'win32') {
try {
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();
if (os.platform() === 'win32') {
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 {
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);
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') {
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 {
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();
});
});
}
}
const message = process.argv[2] || '默认消息:Hello Node.js 命名管道';
sendMessage(message);
| 系统 | 管道路径格式 | 实现方式 |
|---|
| Windows | \\.\pipe<管道名> | 基于 net 模块(类似 TCP) |
| Linux/macOS | /tmp/<管道名>(FIFO 文件) | 基于 fs 模块读写 FIFO 文件 |
2. Socket
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 端口');
});
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 发布订阅)
const { createClient } = require('redis');
const publisher = createClient();
publisher.connect();
setInterval(async () => {
const msg = `当前时间:${new Date().toLocaleString()}`;
await publisher.publish('process-channel', msg);
console.log('发布者发送:', msg);
}, 1000);
const subscriber = createClient();
subscriber.connect();
subscriber.subscribe('process-channel', (msg) => {
console.log('订阅者收到:', msg);
});
线程间的通信
和进程间通信不同,Node.js 的工作线程虽然有独立的 V8 实例和内存,但支持两种通信模式:
- 消息传递(默认):通过复制数据的方式通信(序列化 / 反序列化),安全但有少量性能开销;
- 共享内存:通过
SharedArrayBuffer 直接共享内存,无数据复制开销,但需要手动处理并发安全。
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('data', (data) => {
console.log(`worker2 收到 worker1 的消息:${data}`);
worker1.postMessage('hello worker1,我是 worker2!');
});
worker1.postMessage('hello worker2,我是 worker1');
});
3. 高性能方式:共享内存(SharedArrayBuffer)
通过 SharedArrayBuffer 实现线程间内存共享,数据无需复制,适合大数据量传输(如实时计算、数据共享),但需要注意并发安全。
const { Worker } = require('worker_threads');
const sharedBuffer = new SharedArrayBuffer(4);
const sharedArray = new Uint32Array(sharedBuffer);
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);
const { workerData } = require('worker_threads');
const { sharedBuffer, id } = workerData;
const sharedArray = new Uint32Array(sharedBuffer);
for (let i = 0; i < 1000; i++) {
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
netstat -tunlp | grep 8080
fuser 8080/tcp
fuser 8080/udp
什么是编译型语言和解释型语言,他们有什么区别?
- 编译型语言:就像先请翻译把整本外文书翻译成中文书,你之后直接看翻译好的中文书就行。程序运行前,会通过编译器将源代码一次性翻译成机器能直接执行的二进制指令(可执行文件),后续运行时不再需要源代码。
- 解释型语言:就像请翻译逐句给你解释外文书,你看一句,翻译解释一句。程序运行时,由解释器逐行读取源代码、逐行解释执行,不会生成独立的二进制可执行文件。
| 维度 | 编译型语言 | 解释型语言 |
|---|
| 执行流程 | 先编译(一次性翻译)→ 后运行 | 边解释(逐行翻译)→ 边运行 |
| 运行效率 | 运行速度快(直接执行机器码) | 运行速度慢(每次都要解释) |
| 开发调试效率 | 编译报错后需修改重新编译,调试稍慢 | 改代码后可立即运行,调试更灵活 |
| 跨平台性 | 编译后的可执行文件和平台强绑定(如 Windows 编译的 exe 不能在 Linux 运行) | 只要有对应解释器,代码可跨平台运行 |
| 代表语言 | C、C++、Go、Rust、java | Python、JavaScript、PHP、Ruby |
| 优点 | 代码在运行前已经被编译为机器码,运行速度快 | 由于不需要编译成机器码,开发和调试过程通常更快,更灵活 |
| 缺点 | 需要编译步骤,开发和调试较慢 | 运行速度通常比编译型语言慢,因为每次执行都需要进行翻译 |
- 执行速度:编译型语言通常比解释型语言快,因为他们直接运行机器码
- 开发灵活性:解释型语言通常更灵活,适合快速开发和迭代
- 错误检测:编译型语言在编译阶就可以捕获更多的语法和类型错误,而解释型语言通常在运行时才发现错误
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;
b = 20;
console.log(a);
console.log(b);
2. 堆(Heap)—— 存储引用类型
JavaScript 的引用类型会存储在堆中,栈中仅保存指向堆内存的「指针(地址)」:
- 引用类型:Object(包括数组、对象、函数、正则等)
- 特点:占用空间大且动态变化,赋值时仅复制指针(引用传递),多个变量可能指向堆中同一个数据。
let obj1 = { name: "张三" };
let obj2 = obj1;
obj2.name = "李四";
console.log(obj1.name);
console.log(obj2.name);
obj2 = { name: "王五" };
console.log(obj1.name);
console.log(obj2.name);
| 特性 | 栈(Stack) | 堆(Heap) |
|---|
| 存储内容 | 基本类型、引用类型的指针 | 引用类型(对象、数组等) |
| 空间大小 | 固定、小 | 动态、大 |
| 访问速度 | 快(直接访问) | 慢(通过指针间接访问) |
| 内存分配 | 自动分配(函数执行 / 变量声明) | 手动 / 引擎分配(需垃圾回收) |
| 回收机制 | 函数执行完自动释放 | 需 JS 垃圾回收器(GC)清理 |
- 栈内存:函数执行上下文出栈时,对应的变量会被立即释放,无需垃圾回收。
- 堆内存:当一个对象不再被任何变量(栈中的指针)引用时,垃圾回收器会在合适时机清理这块内存,避免内存泄漏。
简述 JS 垃圾回收的过程。用什么算法?
首先,我们可以用一个通俗的比喻来理解:JS 引擎就像一个管家,内存是家里的储物空间。当你创建变量、对象、函数时,管家会分配空间存放;垃圾回收就是管家定期清理那些你再也用不到的'杂物'(不再被引用的内存),释放空间避免堆积。
核心原则:找出不再使用的变量 / 对象,释放其占用的内存。
二、JS 垃圾回收的主要算法
JS 引擎(如 V8)主要使用两种核心算法,且会根据数据大小 / 类型选择不同策略:
1. 引用计数法(早期算法,有缺陷)
- 原理:跟踪每个值被引用的次数。
- 当一个值被创建并赋值给变量时,引用数 = 1;
- 若该值被其他变量引用,引用数 +1;
- 若引用它的变量被覆盖 / 销毁,引用数 -1;
- 当引用数变为 0 时,说明该值无法被访问,会被回收。
- 缺陷:无法解决循环引用问题(比如两个对象互相引用,即使都不再被外部使用,引用数也永远不为 0)。
function fn() {
let obj1 = {};
let obj2 = {};
obj1.a = obj2;
obj2.b = obj1;
}
fn();
2. 标记清除法(现代 JS 引擎主流算法)
这是目前 Chrome/V8、Node.js 等环境的核心算法,解决了循环引用问题。
- 原理(分两步):
- 标记阶段:从根对象(全局对象 window/global、执行栈中的变量等)出发,遍历所有可访问的对象,给这些'可达'的对象打上标记;
- 清除阶段:清理所有未被标记的对象(即'不可达'的对象),释放其内存。
- 优势:即使对象循环引用,只要它们无法从根对象访问到,就会被标记为垃圾并清除。
function fn() {
let obj1 = {};
let obj2 = {};
obj1.a = obj2;
obj2.b = obj1;
}
fn();
3. 分代回收(V8 优化策略)
- 新生代(Young Generation):存放短期存活的对象(如临时变量),空间小(几 MB),回收频率高,采用 Scavenge 算法(将内存分为 From/To 两个区域,复制存活对象到 To 区,清空 From 区,然后交换两区角色);
- 老生代(Old Generation):存放长期存活的对象(如全局变量),空间大,回收频率低,主要用 标记 - 清除 + 标记 - 整理 算法(标记清除后,会整理内存碎片,避免内存不连续)。
闭包为什么不会被销毁
JavaScript 有自动垃圾回收机制,它的核心判断逻辑是:如果一个对象 / 变量没有任何可达的引用(即'无人使用'),就会被标记为可回收,最终销毁并释放内存。
闭包不会被销毁,本质是打破了这个规则 —— 闭包让内部函数保留了对外部函数作用域的引用,导致外部函数的作用域始终有'可达引用',因此不会被回收。
function outer() {
let count = 0;
function inner() {
count++;
console.log(count);
}
return inner;
}
const fn = outer();
fn();
fn();
不是所有闭包都不会销毁:如果闭包没有被外部引用(比如内部函数只在外部函数内部调用,没有返回 / 赋值给外部变量),那么外部函数执行完后,闭包和对应的作用域会被正常回收。
闭包不销毁≠内存泄漏:合理使用闭包(比如用完后手动切断引用)不会造成内存泄漏;只有滥用闭包(比如长期保留不必要的闭包引用)才会导致内存占用过高。
什么是内存泄漏?如何排查?JS 内存泄漏的常见原因?
内存泄露是指在程序运行过程中,程序未能释放不再使用的内存空间,导致内存资源被浪费。
- 使用内存分析工具
- 浏览器开发者工具:Chrome 的 DevTools 提供了内存分析工具 Memory,可以监控内存使用情况
- 也可以结合 setInterval 使用 console.memory 查看内存使用的快照
- 代码审查
- 检查代码中是否有未释放的事件监听器,定时器,全局变量,确保不再需要某对象时,及时解除引用
- 性能监控
- 监控应用程序的内存使用情况,观察是否有持续增长的趋势
- 使用日志记录内存使用情况,帮助识别内存泄露的模式
- 意外的全局变量:忘记使用 var,let,const 声明变量时,变量会被挂载到全局对象上
- 闭包:闭包中引用了不再需要的外部变量,导致这些变量无法被垃圾回收
- 未清理的 DOM 引用:删除 DOM 元素时,未能清理相关的事件监听器或引用
- 定时器和回调:未能清理不再需要的 setInterval 或 setTimeout 回调
冯·诺依曼架构是什么?
- 输入设备:键盘,鼠标,摄像头等
- 输出设备:显示器,打印机,扬声器等
- 存储器:计算机的记忆装置,主要存放数据和程序。分为内部存储器(内存/主存储器)和外部存储器(硬盘,光盘,U 盘等)
- 内存:也称之为主存储器,又分为随机存储器(RAM)和只读存储器(ROM)
- RAM 存放的是计算机在通电运行的过程中即时的数据,计算机的内存容量就是指的 RAM 的容量。RAM 可读,可写,断电会数据丢失
- ROM 存放的是每次计算机开机都需要处理的,固定不变的程序和数据,比如 BIOS 程序。ROM 可读,不可写,断电不会丢失
- 外存:外存是硬盘,是计算机的辅助存储器,可以长期保存数据,断电不会丢失。当计算机需要从外存读取数据时,需要将数据从外存读取到内存中,然后才能下一步处理。根据介质不同,外存可分为软盘,硬盘,光盘。硬盘最为常见,硬盘又分为机械硬盘(HD)和固态硬盘(SSD)。
- 运算器:算术逻辑单元(ALU),负责执行算术和逻辑运算
- 控制器:控制整个计算机系统的工作流程,包括指令的执行顺序,数据传输等,运算器和控制器通常集成在一起,就是我们熟知的 CPU
计算机内部为何使用二进制?
- 硬件实现简单:二进制只需要两个状态,通常用电压的高低来表示(如高电压表示 1,低电压表示 0)。这种简单的状态切换使得硬件电路设计更为简单和可靠
- 抗干扰能力强:在电路中,二进制的两个状态(0 和 1)可以通过明显的电压差来区分,这使得系统对噪声和干扰的容忍度更高,数据传输更稳定
- 逻辑运算方便:计算机的基本运算是逻辑运算,二进制系统与布尔代数非常契合,能够进行与,或,非等逻辑运算,简化了计算机的设计和操作
- 存储和处理效率高:二进制数据在计算机中可以直接存储和处理,避免了其他进制系统转换带来的复杂性和效率损失
- 历史和标准化:从计算机发展的早期,二进制就被广泛采用,形成了标准化的设计和技术积累,进一步推动了其普及和应用
什么是虚拟内存,为何要使用虚拟内存?
- 让每个程序都以为自己独占一大片连续的内存地址(虚拟地址)
- 实际物理内存(内存条)很小,系统会把这些'虚拟地址'映射到真实的物理内存或硬盘上
- 程序只管使用虚拟地址,不用关心数据到底在内存还是硬盘
为什么要用虚拟内存?(核心 4 点)
- 让程序不用管物理内存多大:程序写死用虚拟地址,不用考虑内存条大小,兼容性极强。
- 让内存'看起来更大':物理内存不够时,系统把暂时不用的数据放到硬盘(页面文件/swap),相当于用硬盘当'临时内存',能同时跑更多程序。
- 让每个程序互相隔离、更安全:每个进程有独立虚拟地址空间,一个程序崩溃 / 出错,不会搞崩整个系统或其他程序。
- 解决'内存碎片'问题:物理内存可能零零碎碎,但虚拟内存永远是连续的,程序申请大块内存时更方便。
一句话总结
虚拟内存就是操作系统给程序画的'大饼':让程序以为内存很大、连续、独占,实际由系统偷偷管理真实物理内存和硬盘,既省硬件,又安全稳定。
什么是 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)
5. 网络层(Network Layer)
6. 数据链路层(Data Link Layer)
7. 物理层(Physical Layer)
一个域名对应一个 ip 吗
1. 一个域名 → 多个 IP
- 比如:
baidu.com 会解析到一堆 IP
- 你访问时,DNS 会返回其中一个
- 多用于大型网站、CDN、云服务
2. 一个 IP → 多个域名
- 一台服务器一个 IP,但上面跑几十个网站
- 浏览器请求时会带上 Host 头,服务器知道你要访问哪个站
简单记
- 域名 → 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. 最直观对比表
| 特点 | TCP | UDP | HTTP |
|---|
| 层级 | 传输层 | 传输层 | 应用层 |
| 可靠性 | 可靠 | 不可靠 | 可靠(基于 TCP) |
| 连接 | 面向连接 | 无连接 | 短连接 / 长连接 |
| 速度 | 慢 | 极快 | 较慢 |
| 有序性 | 有序 | 无序 | 有序 |
| 底层依赖 | IP | IP | TCP |
| 特性 | TCP | UDP |
|---|
| 连接 | 必须先建立连接(三次握手) | 无需连接,直接发数据 |
| 可靠性 | 可靠,不丢不乱序 | 不可靠,可能丢包、乱序 |
| 速度 | 慢,开销大 | 快,开销极小 |
| 流量 / 拥塞控制 | 有 | 无 |
| 数据形式 | 字节流 | 数据报(一包一包) |
| 重传机制 | 有 | 无 |
5. 应用场景(最实用部分)
TCP 场景(要求不丢、不错、不乱)
- 网页浏览(HTTP/HTTPS)
- 文件传输(FTP、HTTP 下载)
- 邮件(SMTP、POP3)
- 登录、支付、接口请求
UDP 场景(要求快、实时,丢一点没关系)
- 直播、实时音视频(抖音、微信通话)
- 游戏(王者荣耀、吃鸡)
- DNS 查询
- IoT 设备上报、实时监控
HTTP 场景(业务接口、网页、API)
- 网站、H5、小程序请求
- RESTful API、后端接口交互
- 文件上传 / 下载
- 登录、支付、查询等必须可靠的业务
相关免费在线工具
- 加密/解密文本
使用加密算法(如AES、TripleDES、Rabbit或RC4)加密和解密文本明文。 在线工具,加密/解密文本在线工具,online
- Gemini 图片去水印
基于开源反向 Alpha 混合算法去除 Gemini/Nano Banana 图片水印,支持批量处理与下载。 在线工具,Gemini 图片去水印在线工具,online
- Keycode 信息
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具,Keycode 信息在线工具,online
- Escape 与 Native 编解码
JavaScript 字符串转义/反转义;Java 风格 \uXXXX(Native2Ascii)编码与解码。 在线工具,Escape 与 Native 编解码在线工具,online
- JavaScript / HTML 格式化
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具,JavaScript / HTML 格式化在线工具,online
- JavaScript 压缩与混淆
Terser 压缩、变量名混淆,或 javascript-obfuscator 高强度混淆(体积会增大)。 在线工具,JavaScript 压缩与混淆在线工具,online