jemalloc 内存分配器 是什么?

内存池
所谓内存池，是指应用程序向操作系统（或 JVM）申请一块内存，自己管理这一块内存，对象的创建和销毁都从这块内存中分配和回收，这么一块内存就可以称作内存池，

对应地，管理这块内存的工具就称作内存分配器。
同时，对于申请对象的不同又可以分为堆内存池和直接内存池，
1 如果是向 JVM 申请的内存，那就是堆内存池，
2 如果是向操作系统申请的内存，那就是直接内存池。

那么，有哪些内存分配器呢？

业界比较著名的有三个内存分配器：
1 ptmalloc，Doug Lea 编写的分配器，支持每个线程（per-thread，简称 pt）的 arena，glibc 的默认分配器。
Doug Lea 大神还有个分配器叫作 dlmalloc，dl 即其名之缩写。
2 tcmalloc，Google 的分配器，它加入了线程缓存（thread cache，简称 tc），Google 声称其比 ptmalloc 快 6 倍。

3 jemalloc，Jason Evans 的分配器，je 即其名之缩写，借鉴了很多 tcmalloc 的优秀设计，声称比 tcmalloc 更快，且 CPU 核数越多优势越大，当然，算法也更复杂。

目前，jemalloc 已经广泛运用在 facebook、Mozilla、FreeBSD 等公司的产品上，那么，它有怎样的优势呢？

简单总结一下，主要有三大优势：
1 快速分配和回收
2 内存碎片少
3 支持性能分析

当然了，以上说的都是原生的 jemalloc，我们今天要讲的是 Netty 中的 jemalloc，它是原生 jemalloc 在 Java 中的一种实现方式，并根据 Java 语言自身的特点做了一些删减和优化。

我们先从宏观方面对 Netty 中的内存池有个全面的了解，在 Netty 中，主要包含上面这些组件：

PoolArena
PoolChunkList
PoolChunk
PoolSubpage
PoolThreadCache

PoolArena
根据内存方式的不同，PoolArena 分成 HeapArena 和 DirectArena 两个子类，在创建 PooledByteBufAllocator 的时候会分别初始化这两种类型的 PoolArena 数组，数组默认大小为核数的 2 倍，同时也会根据可以使用的内存大小动态调整。
public class PooledByteBufAllocator extends AbstractByteBufAllocator implements ByteBufAllocatorMetricProvider {
private final PoolArena<byte[]>[] heapArenas;
private final PoolArena[] directArenas;
}

核数也可以通过 JVM 启动参数 io.netty.availableProcessors 配置，因为如果使用低版本的 JDK 且部署在 docker 容器中，获取的是主机的核数，而不是 docker 容器分配的核数。

PoolArena 中存储着 2 种类型的数据结构，分别为 2 个 PoolSubPage [] 数组和 6 个 PoolChunkList：

abstract class PoolArena<T> implements PoolArenaMetric {
	private final PoolSubpage<T>[] tinySubpagePools;
    private final PoolSubpage<T>[] smallSubpagePools;
    private final PoolChunkList<T> q050;
    private final PoolChunkList<T> q025;
    private final PoolChunkList<T> q000;
    private final PoolChunkList<T> qInit;
    private final PoolChunkList<T> q075;
    private final PoolChunkList<T> q100;
}

为什么这么复杂呢？一切都是为了更好地利用内存。

实际上，所有的数据都存储在叫作 PoolChunk 的对象中，默认每个 PoolChunk 可以存储 16MB 的数据（chunkSize），每个 PoolChunk 内部又使用伙伴算法将这 16MB 拆分成 2048 个 Page，每个 Page 的大小（pageSize）为 16MB/2048=8KB。

如果分配的内存（规范化后的内存）小于 8KB，则把 Page 拆分成更小的内存块，并使用 PoolSubpage 管理这些更小的内存，每个 Page 的拆分标准根据这个 Page 首次被分配时的请求的大小决定：

1 如果小于 512B，则按照 16B 规范化，比如请求的大小为 30B，则规范化到 32B，然后 PoolSubpage 中的元素大小就是 32B，那么，这个 Page 就被拆分成了 8KB/32B=256 个更小的内存块。

2 如果大于等于 512B，则按照 512B*(2^n) 规范化，比如请求的大小为 996B，那就规范化到 1024B，也就是 1KB，然后这个 Page 就被拆分成了 8KB/1KB=8 个更小的内存块。

如果分配的内存大于等于 8KB，且小于等于 16MB，则按照 Page 的大小，也就是 8KB，进行规范化，然后再根据伙伴算法的规则进行内存的分配，什么是伙伴算法呢？我们待会讲。
如果分配的内存大于 16MB，则按照非池化的方式分配内存。
所以，为了区分以上几种情况，Netty 中定义了一个 SizeClass 类型的枚举，把这几种情况分别叫作 Tiny、Small、Normal、Huge，其中 Huge 不在这个枚举中。

对于 Tiny 和 Small 类型，Netty 为了快速定位，定义了两个数组放在 PoolArena 中，分别是 tinySubpagePools 和 smallSubpagePools，它们的大小分别为 32 和 4，如果这两个数组对应的位置有值，说明之前出现过相同大小的内存块，那就快速定位到那个 PoolSubpage，使用它直接分配内存，而不用再从头查找，加快分配内存的速度。

前面我们说了，实际上，所有的数据都位于 PoolChunk 中，为了更好地管理这些 PoolChunk，Netty 将它们以双向链表的形式存储在 PoolChunkList 中，同时 PoolChunkList 本身也以双向链表的形式呈现。

在 PoolArena 中，定义了 6 个 PoolChunkList，分别是 qInit、q000、q025、q050、q075、q100，Netty 根据 PoolChunk 的使用率将它们放到不同类型的 PoolChunkList 中，它们代表的使用率分别为：

qInit，内存使用率为 Integer.MIN_VALUE ~ 25%，当然不可能有负的使用率，所以最小应该是 0
q000，内存使用率为 0 ~ 50%
q025，内存使用率为 25% ~ 75%
q050，内存使用率为 50% ~ 100%
q075，内存使用率为 75% ~ 100%
q100，内存使用率为 100% ~ Integer.MAX_VALUE，当然不可能有超过 100% 的使用率，所以最大应该是 100%

举个例子来说明，比如一个 Chunk 首次分配了大小为 512B 的内存，那么它的内存使用率就是 512B/16MB 不足 1%，向上取整为 1%，初始时放在 qInit 中，当其分配的总内存超过了 4MB 的时候，也就是达到 25% 了，这个 PoolChunk 就被移动到 q000 中，同样地，当其分配的内存超过 8MB 的时候，就移动到了 q025 中。反过来也是一样，当有对象释放内存时，这部分内存又会被回收到 PoolChunk 中待分配，这时候内存使用会降低，当降低到 4MB 时，也就是 q025 的下限，则会将这个 PoolChunk 移动到 q000 中。

PoolChunkList

正如前面所说，PoolChunkList 就是相近内存使用率的 PoolChunk 的集合，这些 PoolChunk 以双链表的形式存储在 PoolChunkList 中，而 PoolChunkList 本身也以双向链表的形式连在一起，为什么要以双向链表的形式存在呢？

其实，这包含两个问题：
1 PoolChunk 以双向链表的形式存在，是为了删除元素（移动 PoolChunk）的时候更快，比如，要删除 chunk2，只要把它的 prev 和 next 连一起就行了，时间复杂度更低；
2 PoolChunkList 以双向链表的形式存在，是为了让 PoolChunk 在 PoolChunkList 之间移动更快，比如，一个 PoolChunk 不管是从 q025 到 q050，还是从 q050 回到 q025，都很快，时间复杂度都很低；

另外，在 Netty 中，当分配内存时，优先从 q050 中寻找合适的 PoolChunk 来分配内存，为什么先从 q050 开始呢？

private void allocateNormal(PooledByteBuf<T> buf, int reqCapacity, int normCapacity) {
    if (q050.allocate(buf, reqCapacity, normCapacity) 
        || q025.allocate(buf, reqCapacity, normCapacity) 
        || q000.allocate(buf, reqCapacity, normCapacity) 
        || qInit.allocate(buf, reqCapacity, normCapacity) 
        || q075.allocate(buf, reqCapacity, normCapacity)) {
        return;
    }
    // 省略其它代码
}

因为 q050 中的 PoolChunk 的内存使用率都比 50% 多一点，这样更容易找到符合条件的 PoolChunk，又不至于使 PoolChunk 的利用率偏低。

因为 q050 中的 PoolChunk 的内存使用率都比 50% 多一点，这样更容易找到符合条件的 PoolChunk，又不至于使 PoolChunk 的利用率偏低。

我们举个例子，假如从 q075 中先寻找，如果要分配 4M 以上的内存就无法找到合适的 PoolChunk；假如从 q025 中先寻找，可能正好有内存使用率在 25% 以上的 PoolChunk，这时候就直接使用了，那么 q050 中的 PoolChunk 就很难被利用起来，也就是 q050 中的 PoolChunk 的剩余空间很难被利用起来，进而导致整体的利用率偏低，也就是内存碎片会变高。

那么，如果先从 q050 寻找合适的 PoolChunk 呢？这时 q025 和 q075 中的 PoolChunk 可能永远都不会被使用到，不过没关系，对于 q025 中的 PoolChunk 的内存使用率变为 0 的时候，它们自然就被释放了，而 q075 中的 PoolChunk 本身内存使用率就已经很高了，不用到它们反而更好，等它们的内存使用率降低的时候就又回到 q050 中了，此时就又来很容易地被利用起来。

因此，从 q050 开始寻找，能很大程度上增大整体的内存使用率，降低内存碎片的存在。

PoolChunk
前面我们说了，默认地，一个 PoolChunk 可以存储 16MB 的数据，PoolChunk 是真正存储数据的地方，何以见得？

final class PoolChunk<T> implements PoolChunkMetric {
    // 数据存储的地方
    final T memory;
    // 满二叉树对应节点是否被分配，数组大小为4096
    private final byte[] memoryMap;
    // 满二叉树原始节点高度，数组大小为4096
    private final byte[] depthMap;
    // 管理更小的内存，数组大小为2048
    private final PoolSubpage<T>[] subpages;
    // 剩余的内存
    private int freeBytes;
    PoolChunk<T> prev;
    PoolChunk<T> next;
}

PoolChunk 本身是一个泛型类型，内部保存了一个叫作 memory 的变量，这个 memory 会根据分配的是堆内存还是直接内存而变换类型：
对于堆内存，memory 的类型为 byte []
对于直接内存，memory 的类型为 ByteBuffer，实际上为 DirectByteBuffer。

所有的数据都存储在 memory 中，至于更小粒度的划分，比如 PoolSubpage，它们使用各种偏移量对 memory 进行分段处理，数据本身并不会复制到这些细粒度的类中。

在 Netty 中，并没有 PoolPage 或者 Page 这个类，Page 是一种抽象的说法，
它表示的是 PoolChunk 中每 8KB 的数据块，它同样使用 PoolSubpage 来表示。

默认地，Netty 使用伙伴算法将 PoolChunk 分成 2048 个 Page，这些 Page 又向上形成一颗满二叉树：

结合上图，我们先来简单介绍一下 PoolChunk 中的几个变量：

depthMap，保存着满二叉树原始的高度信息，比如 depthMap [1024]=10

memoryMap，初始值等于 depthMap，随着节点的被分配，它的值会不断变化，更新子节点的值时，会同时更新其父节点的值，其父节点的值等于两个子节点值中的最小者。

subpages，对应于上图中的 Page0、Page1、…、Page2047，在 Netty 中并没有 Page 的具体代码实现，它同样使用 PoolSubpage 来表示。只有分配的内存小于 8KB，才会使用 PoolSubpage 进行管理，在 PoolSubpage 创建之后，会加入到 PoolArena 中 tinySubpagePools [] 或 smallSubpagePools [] 对应位置的链表中，同时，在 PoolSubpage 代表的内存被分配完之后，会从对应的链表中删除，也就是说，在同一时刻，head 最多只会与一个 PoolSubpage 形成双向链表。

freeBytes，PoolChunk 中剩余的内存，即可被使用的内存。

如果分配的内存大于等于 8KB，由 PoolChunk 自己管理。

为了更好地理解伙伴分配算法，我们来假想一种分配内存的情况，如果分配内存的顺序分别为 8KB、16KB、8KB，则会按以下顺序进行：

8KB，符合一个 Page 大小，所以从第 11 层（12-8KB/8KB）寻找节点，这里找到了 2048 这个节点，发现其 memoryMap [2048]=11=depthMap [2048]，可以被分配，然后到其对应的 Page [0] 中分配内存，分配之后将其 memoryMap [2048]=12，memoryMap [1024]=11=（2048 和 2049 中的最小者 11），memoryMap [512]=10=（1024 和 1025 中的最小者 10），…，memoryMap [1]=1；

16KB，符合两个 Page 大小，所以从第 10 层寻找节点（12-16KB/8KB），找到 1024 节点，发现其 memoryMap [1024]=11!=depthMap [1024]，不符合条件，继续寻找到 1025 节点，发现其 memoryMap [1025]=10=depthMap [1025]，符合条件，所以，到其对应的叶子节点 2050/2051 对应的 Page [2]/Page [3] 中分配内存，分配之后 memoryMap [2050]=12，memoryMap [2051]=12，memoryMap [1025]=12=（2050 和 2051 中的最小值 12），memoryMap [512]=11=（1024 和 1025 中的最小者 11），…，memoryMap [1]=1；

8KB，符合一个 Page 大小，所以从第 11 层（12-8KB/8KB）寻找节点，2048 已经不符合条件了，所以找到了 2049 这个节点，到其对应的 Page [1] 中分配内存，然后更新 memoryMap [2049]=12，memoryMap [1024]=12=（2048 和 2049 中的最小者 12），memoryMap [512]=12=（1024 和 1025 中的最小者 12），…，memoryMap [1]=1；

至此，三次内存都分配完毕，总共分配了 Page0~Page3 共 4 个 Page，从分配结果也可以看出，使用伙伴分配算法，能极大地保证分配连续的内存空间，并减少内存碎片的诞生。

PoolSubpage
前面我们说过，只有当分配的内存小于一个 Page 大小，即 8KB 时，才会使用 PoolSubpage 来进行管理，那么它是怎么管理的呢？

让我们先来看看它的几个关键字段：

final class PoolSubpage<T> implements PoolSubpageMetric {
    // 对应满二叉树中的哪个节点
    private final int memoryMapIdx;
    // 在PoolChunk的memory中的偏移量
    private final int runOffset;
    // 表示每个小块的状态
    private final long[] bitmap;
    // 每个小块（元素）的大小
    int elemSize;
    // 最大的元素个数=8KB/elemSize
    private int maxNumElems;
    // 需要使用到几个long
    private int bitmapLength;
    // 可用的元素个数
    private int numAvail;
    // 双向链表的指针
    // 与PoolArena中的tinySubpagePoos或smallSubpagePools中的元素形成双向链表
    PoolSubpage<T> prev;
    PoolSubpage<T> next;
}

elemSize 表示每个元素的大小，这个大小是根据这个 Page 接收到的第一个请求的大小决定的。
比如，首次分配 30B 的内存，则会经历以下几个步骤：

1判断小于 512B，按 16B 向上规范化到 32B；
2 在满二叉树的第 11 层寻找一个可用的节点，假如是 2049，即 memoryMapIdx=2049，它代表的是 Page1，Page1 这个节点在 PoolChunk 中对应到 memory 上的偏移量就是 8192（前面有个 Page0），所以，runOffset=8192；
3 此时，会把 Page0 按 32B 分成（8KB/32B=256）个小块，所以，elemSize=32B，maxNumElems=256，numAvail=256；
4 同时，这 256 个小块就需要 256 个 bit（位）来表示其每个小块的状态，也就是需要（256/64=4）个 long 类型来表示，所以，bitmapLength=4；
5 然后，把这个 PoolSubpage 与 PoolArena 的 tinySubpagePools [1]（相当于 head）形成双向链表，因为 tinySubpagePools [0] 代表的是 16B 的内存，tinySubpagePools [1] 代表的是 32B 的内存；
6 当分配完这 32B 之后，可用节点数减一，所以，numAvail=255；

当再次分配规范为 32B 内存的时候，就看 PoolArena 的 tinySubpagePools [1] 的 next 中有没有值，有值，就直接使用其分配内存了，而不用再重新走一遍上面的过程，从而加快分配内存的速度。

PoolThreadCache
前面讲了这么多，分配内存的速度已经足够快了，但是，还可以更快，那就是加入线程缓存 PoolThreadCache，那么，PoolThreadCache 在何时使用呢？

其实，这要结合回收内存一起使用，当回收内存时，先不还给 PoolChunk，而是使用本地线程缓存起来，当下一次再分配同样大小（规范化后的大小）的内存时，先尝试从本地线程缓存里面取，如果取到了就可以直接使用了。

那么，PoolThreadCache 可以缓存哪些类型的缓存呢？

在 Netty 中，除了 Huge，其它类型的内存都可以缓存，即 Tiny、Small、Normal，当然，根据堆内存和直接内存的不同，PoolThreadCache 中又分成了两大类：

final class PoolThreadCache {
    // 堆内存的缓存
    private final MemoryRegionCache<byte[]>[] tinySubPageHeapCaches;
    private final MemoryRegionCache<byte[]>[] smallSubPageHeapCaches;
    private final MemoryRegionCache<byte[]>[] normalHeapCaches;
    // 直接内存的缓存
    private final MemoryRegionCache<ByteBuffer>[] tinySubPageDirectCaches;
    private final MemoryRegionCache<ByteBuffer>[] smallSubPageDirectCaches;
    private final MemoryRegionCache<ByteBuffer>[] normalDirectCaches;
}

PoolThreadCache 中使用了一个叫作 MemoryRegionCache 的类来做缓存，它内部维护了一个队列，当回收内存时，这块内存进入到这个队列中，当下次再分配同样大小（规范化后的大小）的内存时，从这个队列中取，关于 PoolThreadCache 的使用，我们下一节结合代码一起学习。

一、归集与分配概念

  1、成本归集：通过一定的会计制度以有序的方式进行成本数据的收集或汇总。例如制造费用按车间归集。

  2、成本分配：将归集的间接成本分配给成本对象，也叫间接费用的分摊。

  3、成本的核算账户设置

    成本核算账户包括：基本生产成本（总账与明细账）、辅助生产成本、制造费用

二、生产的归集与分配

  1、材料的归集与分配：材料费用包括企业在生产经营过程中实际消耗的各种原材料及主要材料、辅助材料、外购半成品等

        基本生产车间发生的直接用于产品生产的材料成本，直接计入该产品成本“直接材料”成本项目中；

        如果是几种产品共同耗用的材料成本，则应采用适当的分配方法，分配计入各有关产品成本的“直接材料”成本项目；

        依据用途分别归入直接材料、制造费用、管理费用。

   2、材料费用计算步骤：

      （1)  计算各种产品的材料定额消耗量或材料定额成本：材料定额消耗量=产品投产量*单位消耗定额

      （2）计算材料费用分配率：材料费用分配率=材料实际总消耗量/各种产品材料定额消耗量之和

      （3)  计算各种产品应负担的材料费用：某种产品应分配的材料数量=该产品的材料定额消耗量*分配率

  3、人工费用核算：

      （1）人工费用包括工资和福利费用

      （2）人工归集与分配

  3、辅助生产费用的归集与分配

      （1）辅助生产：为基本生产车间服务而进行的产品生产和劳务供应，主要任务是为企业内部的生产和管理服务

      （2）辅助生产成本的归集：辅助生产成本账户

               发生直接成本——”辅助生产成本“账户

               发生制造费用——”制造费用“账户——”辅助生产成本“账户

     

   （3）归集程序：

            发生直接成本时（直接材料、直接人工）：借（辅助生产成本——XX车间） 贷（原材料/应付职工薪酬）

            发生制造费用（折旧费、水电费等）时：借（制造费用）  贷（累计折旧/银行存款/周转材料等）

           PS：如果辅助生产车间不对外提供商品，且规模较小，制造费用少，也可直接计入“辅助生产成本”账户及明细账。

  （4）辅助生产费用的分配：

            按照收益原则将辅助生产车间为提供产品或提供劳务而发生的消耗转嫁给使用产品或接受劳务的其他部门。

            产品性生产：账务处理同基本生产车间生产产品一样

            劳务性生产：按收益原则，在各受益单位之间进行分配

            分配方法： 直接分配法（不考虑辅助生产车间之间相互提供产品或劳务的情况，而是将各种辅助生产费用直接分配给辅助生产车间以外的收益单位，忽略辅助车间之间的业务往来，计算便利，但影响计算完整性适宜在辅助生产内部相互提供劳务、作业不多，不进行费用的交互分配，对辅助生产成本和企业产品成本影响不大的情况下采用）

            顺序分配法（按辅助车间收益的多少排列先后顺序，受益少的排在前面，按此顺序分配费用的方法，排在前面的辅助生产车间不承担后一个车间的费用，后者的分配额=其直接费用+前者分配来的费用，修正直接分配法的不足，关键是确定费用分配顺序）

           交互分配法（首先根据各辅助生产车间相互提供劳务的数量及交互分配前的劳务单位成本/计划单位成本在各辅助生产车间之间进行一次交互分配，然后将各辅助生产车间交互分配后的实际费用，按照对辅助生产生产车间以外部门提供劳务的数量及交互分配后的单位成本，分配给辅助生产车间以外的各受益部门，即先在各辅助生产车间之间进行分配，再对除辅助生产以外的受益对象进行分配，计算量大，且各辅助车间的劳务结算只能等其他辅助车间费用转入后才能计算实际费用，影响成本分配的及时性，适用于各辅助生产费用水平相差不大的企业）

           计划分配法（按产品或者劳务的计划单位成本和实际耗用数量进行辅助生产费用分配的一种方法，只适用于在辅助生产计划单位成本制定得比较准确的情况下采用）

          代数分配法（先根据解联立方程的原理，计算辅助生产产品或劳务的单位成本，然后根据各受益单位耗用的数量和单位成本分配辅助生产费用的一种方法，计算精确但比较麻烦，适合辅助生产车间较少或会计工作实现了电算化的企业采用）

  4、制造费用的归集与分配

       （1）制造费用的内容：包括企业生产产品、提供劳务而发生的各项，主要有工资和福利费、机物料消耗、折旧费等

       （2）制造费用的归集：“制造费用”

       （3）制造费用的分配：实际分配率分配法（当期制造费用，存在因果关系）、预计分配率分配法（按年度制造费用预算总额、年度计划产量定额工时）

  5、其他费用的归集与分配

     （1）预提和摊销费用：

              预提指固定资产大修费、季节性大修停工损失、财产保险费；

              摊销指经营性租入固定资产的租金、预付保险费

     （2）生产损失：

              废品损失指不可修复废品的生产成本+可修复的废品的修复费用；

              停工损失：停电、供料不足、机器设备发生故障（停工损失）；

                                季节性、大修理期间的停工损失（制造费用）；

                                非常原因引起的停工损失、由于计划安排减产（营业外支出）；

                                应向责任人索赔的停工损失（其他应收款）；

    （3）其他费用：利息、税金等

三、完工产品和在产品成本的分配

  1、在产品及其数量的核算

      （1）在产品含义：企业的在产品是指没有完成全部生产过程，不能作为商品销售的产品

               狭义：在工厂车间内进行加工的在制品，以及正在返修的废品和已完成本车间生产，但尚未验收入库的产品（某个车                           间、某个步骤而言）

               广义：不仅包括狭义在产品，还包括已经完成部分加工阶段，已由中间仓库验收，但还需继续加工的半成品，以及等                           待返修的废品。（整个企业而言）

    （2）在产品的核算：对在产品实物数量的核算，主要包括在产品收发结存的日常核算和在产品的清查两项工作；产品数量的               核算对于正确计算产品成本，加强生产资金管理和保护企业财产的安全，都具有十分重要的意义。

  2、完工产品与在产品成本的分配方法

      企业应根据月末结存在产品数量的多少，月末在产品数量变化的大小，月末在产品价值的大小，在产品成本中各项费用比重    的大小，以及企业定额管理基础工作的扎实与否等方面的因素，采用适当的分配方法。

    （1）在产品与完工产品成本的计算模式：

             本月完工产品成本=月初在产品成本+本月生产费用-月末在产品成本

    （2）在产品成本的计算：

      在产品不计价法：不计算月末在产品成本，即月末在产品成本为零。适用于各月末在产品数量很少，价值很低，且各月在产               品数量稳定。即下月初在产品成本为零，则简化为：本期生产费用=本期完工产品成本

      在产品成本按其年初为固定数计算法：平时月末在产品固定按年初成本计价的方法，年末则根据实地盘点结果确定在产品成               本。适用于各月末在产品数量较少，或者虽然在产品数量较多，但各月末在产品数量变化不大，在这种情况下，月初、               月末在产品成本的差额对完工产品成本影响不大。采用这种方法时，对每年年终的在产品成本，必须根据年终实际盘点               的在产品数量重新计算，以保证产品成本的相对准确性。1-11月计算：本期生产费用=本期完工产品成本                                       12月末计算：本期完工产品成本=期初在产品成本+本期生产费-期末盘点确定在产品成本

     在产品成本按所耗原材料费用计算法：在产品按原材料费用计算，产品的加工费用全部由完工产品负担。适用于各月在产                   品数量变化大，且原材料费用在产品成本中所占费用比重较大。即：本期完工产品成本=材料+人工+制造费用；本期在                 产品成本=材料

     约当产量比例法：将月末在产品的数量按其完工程度折算为相当于完工产品的数量，即约当产量，并将本期产品生产费用按                照完工产品数量和月末在产品的约当产量比例进行分配，计算出完工产品成本和月末在产品成本的方法。适用于月末在                产品数量较多，各月间在产品数量变动较大，产品成本中原材料费用与其他各项费用所占比重相差不大的产品。

    在产品按定额成本计算法：月末在产品以定额成本计价，将其从月初在产品定额成本与本月生产费用之和中扣除，余额即为本             月完工产品成本。即，每月生产费用脱离定额的差异，全部计入当月完工产品成本。适用于定额管理工作较好，各项消耗             定额比较准确、稳定，而且各月末在产品结存数量比较稳定的产品。

                                                                          完工产品成本=月初在产品费用+本月生产费用-月末在产品定额成本

       定额比例法：按完工产品与在产品的定额耗用量（或定额成本）的比例分配生产费用。适用于定额管理基础较好，各项消耗                定额比较健全、稳定，各月末在产品数量变动较大的产品。

       在产品按完工产品计算法：将在产品视同完工产品分配费用的方法。适用于月末在产品以及接近完工，或产品已经加工完                    毕，但尚未验收入库的产品。（与约当产量计算法基本相同，只是程度按100%进行计算）

 

         

 

    

 

 

 

         

           

 

 

  

  

目前主要的接入方式：交换方式，路由模式，混合模式，链路捆绑模式，拨号模式。

1，交换模式：

此模式下，防火墙所有接口都为交换接口。对于同一VLAN的数据包在转发时不做任何改动，包括IP和MAC地址，直接把包转发出去。

当网络已经建立并成熟运行，防火墙的接入是为了增强现有网络的防御能力时一般采用此接入模式。因为在这种模式下接入防火墙，对网络通信造成的影响最少，能够最小限度改动网络节点的网络属性（网络拓扑结构，网络设备地址等）。

交换模式下通信，防火墙会很好的支持VLAN，交换接口的工作模式可以支持ACCESS和TRUNK。对于包的转发，防火墙将不改变通信数据包的包头信息，避免各个防火区域中应用设备管理地址的刷新。

防火墙能够对协议进行深层次分析并且能够识别，处理各类封装格式，如802.1Q，QinQ,MPLS等，以便能够在复杂的网络环境下进行更灵活的接入，处理更多的情况。

（1）：对802.1Q封装格式的处理

IEEE802.1Q俗称“Dot One Q”,是经过IEEE认证的对数据帧附加VLAN识别信息的协议。

IEEE802.1Q所附加的VLAN识别信息位于数据帧中“发送源MAC地址”与“类别域”之间。具体位置为2字节的TPID和2字节的TCI，共计4字节。在数据帧中添加4字节。在数据帧添加了4字节的内容，数据帧上CRC是插入TPID，TCI后对包括他们在内的整个数据帧重新计算后所得到的数值。当数据帧从防火墙接口转发出去时TPID和TCI会被去除，这时还会进行一次CRC的重新计算。TPID的值固定为0X8100.防火墙通过TPID来确定数据帧内附加了基于IEEE802.1Q的VLAN信息。实际的VLAN ID 是由TCI中12位的VLAN标识判断。

（2）对QinQ的处理：

在IEEE802.1Q定义的VLAN Tag域中，只有12位用于表示VLAN ID，所以设备最多可以支持4094个VLAN。但在实际应用中，尤其是在城域网中，需要大量的VLAN来隔离用户，4094个VLAN远远不能满足需求，于是QinQ技术应运而生。

防火墙开启端口的QinQ功能后，当该端口接收到报文，无论报文是否带有VLAN标签，防火墙都会为该报文打上本端口ACCESS VLAN的VLAN标签，如果是TRUNK口则会打上NATIVEVLAN的VLAN标签。这样，如果接受到已经带有VLAN标签。这样，如果接收到的是带有VLAN标签的报文，该报文就成为双标签的报文；如果接收到的是不带VLAN标签的报文，该报文就成为带有端口默认VLAN标签的报文。

（3）对MPLS报文处理：

MPLS（多标签协议交换）独立于第二层和第三层协议，提供一种方式，将IP地址映射为简单的具有固定长度的标签，用于不同的包转发和包交换技术。

当防火墙工作在透明模式，开启MPLS穿透功能时，对通过防火墙的MPLS报文进行安全策略控制；关闭MPLS穿透功能时，防火墙将直接转发MPLS报文。当防火墙工作在路由模式，直接丢弃报文。

路由模式：

在这种模式下，防火墙类似于一台路由器转发数据包，将接受到数据包的源MAC地址替换为相应接口的MAC地址，然后转发。该模式适用于每个区域都不在同一个网段的情况。和路由器一样，防火墙的每个接口均要根据区域规划配置IP地址。同时，防火墙可以在设置了IP的VLAN之间路由转发。

混合模式：

这个模式就是路由模式和交换模式的结合。

在很多用户网络中，网络基础设施的建设是先于网络安全建设进行的，当用户打算进行网络安全建设时，往往会发现由于初期的网络设计不周全而导致名关建应用是依赖于网络拓扑的。因此在对这些关键应用进行安全防护时，安全设备必须采用交换模式，特别是透明模式接入，而对另外些应用 可能就要采用路由模式接入，这样在同一个网关设备上就需要透明模式和路由模式共存。

      透明模式支持把同一网段的网络区域划分为不同的防火区，主要适用于基于业务的IP分配方案，可以将同-应用 业务的服务器和客户机通过同 网段连接起来，以提高整体网络的通信性能，路由模式支持将路由信息转发到其他防火区，减少防火墙应用带来的网络管理的工作量。网络卫土防火墙路由模式提供完整的静态路由功能，对于中小规模的内部网络完全可以代替内网路由器。如果这两种工作模式不能混合在一起同时 工作,用户网络将会出现由于被割裂而无法实施安全设备接入的困局。同时，防火墙支持NAT工作模式。防火墙甚至可以提供路由+透明+NAT混合模式，可以保证不会因为引入安全需求而破坏用户现有网络的完整性，防火墙可以友好地支持网络扩展，方便防火墙接入各种复杂的网络环境，以满足用户网络多样化的部署需求。

链路捆绑模式：

链路捆绑是指将多个物理端口捆绑在一起， 成为个逻辑端口， 以实现出/入流量在各成员端口中的负荷分担。逻辑链路的带宽增加了大约n-1倍(n为聚合的路数)。聚合后，可靠性大大提高，因为n条链路中只要有一条可以正常工作，则这个链路就可以工作。链路聚合还可以实现负载均衡。防火墙可以根据用户配置的端口负荷分担策略决定报文从哪一” 个成员端口发送到对端的交换机。当防火墙检测到其中? -个成员端口的链路发生故障时，就停止在此端口发送报文，并根据负尚分担策略在利下链路中重新计算报文发送的端口，故障端口恢复后再次重新计算报文发送端口。聚合链路可以通过预先设置的负载均衡算法将流量分配给聚合链路内不同的物理接口，实现链路级的负载均衡功能，也可防止单条班路转发速率过低而出现丢包的现象。防火墙上参与聚合的物理接口具备相同的属性，如相同的速度、单双工模式等。

使用链路捆绑接入模式对网络在增加链路带宽、实现链路传输弹性和冗余等方面是很有效的。