为什么 Golang Fasthttp 选择使用 slice 而非 map 存储请求数据

本文主要是介绍为什么 Golang Fasthttp 选择使用 slice 而非 map 存储请求数据，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在这里插入图片描述

文章目录

- Slice vs Map：基本概念
- 内存分配和性能
- Fasthttp 中的 SliceMap
- 性能优化的深层原因
- - HTTP Headers 的特性
  - CPU 预加载特性
- 结论

Fasthttp 是一个高性能的 Golang HTTP 框架，它在设计上做了许多优化以提高性能。其中一个显著的设计选择是使用 slice 而非 map 来存储数据，尤其是在处理 HTTP headers 时。

为什么呢？

本文将从简单到复杂，逐步剖析为什么 Fasthttp 选择使用 slice 而非 map，并通过代码示例解释这一选择背后高性能的原因

Slice vs Map：基本概念

首先，这个设计选择背后有着深思熟虑的考量，主要围绕性能优化展开。在深入探讨之前，我们需要理解 slice 和 map 在 Go 语言中的基本概念和性能特点。

在这里插入图片描述

Slice：Slice 是对数组的封装，它提供了一个动态大小的、灵活的视图。Slices 的底层实际上是数组，这意味着它们的元素在内存中是连续存储的。
Map：Map 是一种无序的键值对的集合，它通过哈希表实现。Map 提供了快速的查找、添加和删除操作，但这些操作的性能并不总是稳定。

内存分配和性能

在高性能的应用场景中，内存分配和回收是性能的关键因素之一。Fasthttp 在这方面做了优化：

Slice 的内存效率

由于 slice 的元素在内存中是连续存储的，它们访问速度快，且能有效利用 CPU 缓存。此外，slice 可以通过重新切片来复用已有的数组，减少内存分配和垃圾回收的压力。

Map 的内存开销

相比之下，map 的内存开销较大。在 map 中，键和值通常是散布在内存中的，这导致 CPU 缓存利用率不高。而且，map 的增长通常涉及重新哈希和重新分配内存，这些操作在性能敏感的应用中可能成为瓶颈。

Fasthttp 中的 SliceMap

Fasthttp 选择使用自定义的 sliceMap 结构来存储键值对，而非标准的 map。下面是 sliceMap 的一个简化版本和它的 Add 方法：

type kv struct {key []bytevalue []byte
}type sliceMap []kvfunc (sm *sliceMap) Add(k, v []byte) {kvs := *smif cap(kvs) > len(kvs) {kvs = kvs[:len(kvs)+1]} else {kvs = append(kvs, kv{})}kv := &kvs[len(kvs)-1]kv.key = append(kv.key[:0], k...)kv.value = append(kv.value[:0], v...)*sm = kvs
}