mspangolang的简单介绍

本文目录一览：

• 1、prometheus中自带的查询指标定义解析
• 2、Golang 1.14中内存分配、清扫和内存回收
• 3、golang是自动释放内存吗
• 4、（十一）golang 内存分析
• 5、升级mac后arduino出现如下编译问题，急求教！

prometheus中自带的查询指标定义解析

参考： prometheus中文手册

go_gc_duration_seconds：持续时间秒

go_gc_duration_seconds_sum：gc-持续时间-秒数-总和

go_memstats_alloc_bytes：Go内存统计分配字节

go_memstats_alloc_bytes_total：Go内存统计分配字节总数

go_memstats_buck_hash_sys_bytes：用于剖析桶散列表的堆空间字节

go_memstats_frees_total：内存释放统计

go_memstats_gc_cpu_fraction：垃圾回收占用服务CPU工作的时间总和

go_memstats_gc_sys_bytes：圾回收标记元信息使用的内存字节

go_memstats_heap_alloc_bytes：服务分配的堆内存字节数

go_memstats_heap_idle_bytes：申请但是未分配的堆内存或者回收了的堆内存（空闲）字节数

go_memstats_heap_inuse_bytes：正在使用的堆内存字节数

go_memstats_heap_objects：堆内存块申请的量

go_memstats_heap_released_bytes：返回给OS的堆内存

go_memstats_heap_sys_bytes：系统分配的作为运行栈的内存

go_memstats_last_gc_time_seconds：垃圾回收器最后一次执行时间

go_memstats_lookups_total：被runtime监视的指针数

go_memstats_mallocs_total：服务malloc的次数

go_memstats_mcache_inuse_bytes：mcache结构体申请的字节数(不会被视为垃圾回收)

go_memstats_mcache_sys_bytes：操作系统申请的堆空间用于mcache的字节数

go_memstats_mspan_inuse_bytes：用于测试用的结构体使用的字节数

go_memstats_mspan_sys_bytes：系统为测试用的结构体分配的字节数

go_memstats_next_gc_bytes：垃圾回收器检视的内存大小

go_memstats_other_sys_bytes：golang系统架构占用的额外空间

go_memstats_stack_inuse_bytes：正在使用的栈字节数

go_memstats_stack_sys_bytes：系统分配的作为运行栈的内存

go_memstats_sys_bytes：服务现在系统使用的内存

go_threads：线程

jvm_buffer_count_buffers：jvm缓冲区计数缓冲区：

jvm_buffer_memory_used_bytes：jvm缓冲区内存已用字节

jvm_buffer_total_capacity_bytes：jvm缓冲区总容量字节

jvm_classes_loaded_classes：jvm_classes加载的类

jvm_classes_unloaded_classes_total：自Java虚拟机开始执行以来已卸载的类总数

jvm_gc_max_data_size_bytes：jvm_gc_最大数据大小字节：

jvm_gc_memory_allocated_bytes_total：在一个GC之后到下一个GC之前增加年轻代内存池的大小

jvm_gc_memory_promoted_bytes_total：GC之前到GC之后，老年代的大小正向增加的计数

system_cpu_count：Java虚拟机可用的处理器数量

process_uptime_seconds：Java虚拟机的正常运行时间

jvm_threads_states_threads：当前处于NEW状态的线程数

jvm_memory_committed_bytes：可供Java虚拟机使用的已提交的内存量

system_cpu_usage:最近的cpu利用率

jvm_threads_peak_threads：自Java虚拟机启动或重置峰值以来的活动线程峰值

jvm_memory_used_bytes：已用内存量

jvm_threads_daemon_threads：当前活动的守护程序线程数

process_cpu_usage：JVM的CPU利用率

process_start_time_seconds：进程的开始时间

jvm_gc_max_data_size_bytes：老年代的最大内存量

jvm_gc_live_data_size_bytes：full GC老年代的大小

jvm_threads_live_threads：当前活动线程数，包括守护程序线程和非守护程序线程

jvm_buffer_memory_used_bytes：已使用缓冲池大小

jvm_buffer_count_buffers：缓冲区数量

logback_events_total：日志备份事件总计

net_conntrack_dialer_conn_attempted_total：网络连接拨号尝试次数总计

net_conntrack_dialer_conn_closed_total：网络连接拨号器关闭总计

net_conntrack_dialer_conn_established_total：网络连接拨号器建立网络连接总数

net_conntrack_dialer_conn_failed_total：网络连接拨号失败总计

net_conntrack_listener_conn_accepted_total：网络连接监听接受总计

net_conntrack_listener_conn_closed_total：网络连接监听关闭总计

prometheus_rule_evaluation_duration_seconds：所有的 rules(recording/alerting) 的计算的时间（分位值），这个可以用来分析规则是否过于复杂以及系统的状态是否繁忙

prometheus_rule_evaluation_duration_seconds_count：执行所有的 rules 的累积时长，没怎么用到

prometheus_rule_group_duration_seconds：具体的 rule group 的耗时

prometheus_rule_group_interval_seconds：具体的 rule group 的执行间隔（如果没有异常，应该和配置中的一致，如果不一致了，那很可能系统负载比较高）

prometheus_rule_group_iterations_missed_total：因为系统繁忙导致被忽略的 rule 执行数量

prometheus_rule_group_last_duration_seconds：最后一次的执行耗时

prometheus_tsdb_blocks_loaded：当前已经加载到内存中的块数量

prometheus_tsdb_compactions_triggered_total：压缩操作被触发的次数（可能很多，但不是每次出发都会执行）

prometheus_tsdb_compactions_total：启动到目前位置压缩的次数（默认是 2 小时一次）

prometheus_tsdb_compactions_failed_total：压缩失败的次数

prometheus_tsdb_head_chunks：head 中存放的 chunk 数量

prometheus_tsdb_head_chunks_created_total：head 中创建的 chunks 数量

prometheus_tsdb_head_chunks_removed_total：head 中移除的 chunks 数量

prometheus_tsdb_head_gc_duration_seconds：head gc 的耗时（分位值）

prometheus_tsdb_head_max_time：head 中的有效数据的最大时间（这个比较有价值）

prometheus_tsdb_head_min_time：head 中的有效数据的最小时间（这个比较有价值）

prometheus_tsdb_head_samples_appended_total：head 中添加的 samples 的总数（可以看增长速度）

prometheus_tsdb_head_series：head 中保存的 series 数量

prometheus_tsdb_reloads_total：rsdb 被重新加载的次数

prometheus_local_storage_memory_series: 时间序列持有的内存当前块数量

prometheus_local_storage_memory_chunks: 在内存中持久块的当前数量

prometheus_local_storage_chunks_to_persist: 当前仍然需要持久化到磁盘的的内存块数量

prometheus_local_storage_persistence_urgency_score: 紧急程度分数

prometheus_local_storage_memory_chunks：本地存储器内存块

process_resident_memory_bytes：进程内存字节

prometheus_notifications_total （针对Prometheus 服务器）

process_cpu_seconds_total （由客户端库导出）

http_request_duration_seconds （用于所有HTTP请求）

system_cpu_usage：系统cpu使用率

tomcat_cache_access_total：tomcat缓存访问总计

tomcat_global_error_total：tomcat全局错误总计

tomcat_global_received_bytes_total：tomcat_全局接收到的字节总数

tomcat_global_request_max_seconds：tomcat全局请求最大秒数

tomcat_global_request_seconds_count：tomcat全局请求秒数

tomcat_global_request_seconds_sum：tomcat全局请求秒数求和

tomcat_global_sent_bytes_total：tomcat全局发送字节总计

tomcat_servlet_error_total：tomcat_servlet错误总计

tomcat_servlet_request_max_seconds：tomcat_servlet_请求最大秒数

tomcat_servlet_request_seconds_count：tomcat_servlet_请求秒数

tomcat_servlet_request_seconds_sum：tomcat_servlet_请求秒数求和

tomcat_sessions_active_current_sessions：tomcat_当前活跃会话数

tomcat_sessions_active_max_sessions：tomcat_活跃会话最大数量

tomcat_sessions_created_sessions_total：tomcat会话创建会话总数

tomcat_sessions_expired_sessions_total：tomcat过期会话数总计

tomcat_sessions_rejected_sessions_total：tomcat拒绝会话数总计

tomcat_threads_busy_threads：tomcat繁忙线程

tomcat_threads_current_threads：tomcat线程当前线程数

Golang 1.14中内存分配、清扫和内存回收

Golang的内存分配是由golang runtime完成，其内存分配方案借鉴自tcmalloc。

主要特点就是

本文中的element指一定大小的内存块是内存分配的概念，并为出现在golang runtime源码中

本文讲述x8664架构下的内存分配

Golang 内存分配有下面几个主要结构

Tiny对象是指内存尺寸小于16B的对象，这类对象的分配使用mcache的tiny区域进行分配。当tiny区域空间耗尽时刻，它会从mcache.alloc[tinySpanClass]指向的mspan中找到空闲的区域。当然如果mcache中span空间也耗尽，它会触发从mcentral补充mspan到mcache的流程。

小对象是指对象尺寸在（16B，32KB]之间的对象，这类对象的分配原则是：

1、首先根据对象尺寸将对象归为某个SpanClass上，这个SpanClass上所有的element都是一个统一的尺寸。

2、从mcache.alloc[SpanClass]找到mspan，看看有无空闲的element，如果有分配成功。如果没有继续。

3、从mcentral.allocSpan[SpanClass]的nonempty和emtpy中找到合适的mspan，返回给mcache。如果没有找到就进入mcentral.grow()—mheap.alloc()分配新的mspan给mcentral。

大对象指尺寸超出32KB的对象，此时直接从mheap中分配，不会走mcache和mcentral，直接走mheap.alloc()分配一个SpanClass==0 的mspan表示这部分分配空间。

对于程序分配常用的tiny和小对象的分配，可以通过无锁的mcache提升分配性能。mcache不足时刻会拿mcentral的锁，然后从mcentral中充mspan 给mcache。大对象直接从mheap 中分配。

在x8664环境上，golang管理的有效的程序虚拟地址空间实质上只有48位。在mheap中有一个pages pageAlloc成员用于管理golang堆内存的地址空间。golang从os中申请地址空间给自己管理，地址空间申请下来以后，golang会将地址空间根据实际使用情况标记为free或者alloc。如果地址空间被分配给mspan或大对象后，那么被标记为alloc，反之就是free。

Golang认为地址空间有以下4种状态：

Golang同时定义了下面几个地址空间操作函数：

在mheap结构中，有一个名为pages成员，它用于golang 堆使用虚拟地址空间进行管理。其类型为pageAlloc

pageAlloc 结构表示的golang 堆的所有地址空间。其中最重要的成员有两个：

在golang的gc流程中会将未使用的对象标记为未使用，但是这些对象所使用的地址空间并未交还给os。地址空间的申请和释放都是以golang的page为单位（实际以chunk为单位）进行的。sweep的最终结果只是将某个地址空间标记可被分配，并未真正释放地址空间给os，真正释放是后文的scavenge过程。

在gc mark结束以后会使用sweep()去尝试free一个span；在mheap.alloc 申请mspan时刻，也使用sweep去清扫一下。

清扫mspan主要涉及到下面函数

如上节所述，sweep只是将page标记为可分配，但是并未把地址空间释放；真正的地址空间释放是scavenge过程。

真正的scavenge是由pageAlloc.scavenge()—sysUnused()将扫描到待释放的chunk所表示的地址空间释放掉（使用sysUnused()将地址空间还给os）

golang的scavenge过程有两种：

golang是自动释放内存吗

golang是一门自带垃圾回收的语言，它的内存分配器和tmalloc(thread-caching malloc)很像，大多数情况下是不需要用户自己管理内存的。最近了解了一下golang内存管理，写出来分享一下，不正确的地方请大佬们指出。

1.内存池:

应该有一个主要管理内存分配的部分，向系统申请大块内存，然后进行管理和分配。

2.垃圾回收:

当分配的内存使用完之后，不直接归还给系统，而是归还给内存池，方便进行下一次复用。至于垃圾回收选择标记回收，还是分代回收算法应该符合语言设计初衷吧。

3.大小切分:

使用单独的数组或者链表，把需要申请的内存大小向上取整，直接从这个数组或链表拿出对应的大小内存块，方便分配内存。大的对象以页申请内存，小的对象以块来申请，避免内存碎片，提高内存使用率。

4.多线程管理:

每个线程应该有自己的内存块，这样避免同时访问共享区的时候加锁，提升语言的并发性，线程之间通信使用消息队列的形式，一定不要使用共享内存的方式。提供全局性的分配链，如果线程内存不够用了，可向分配链申请内存。

这样的内存分配设计涵盖了大部分语言的，上面的想法其实是把golang语言内存分配抽象出来。其实Java语言也可以以同样的方式理解。内存池就是JVM堆，主要负责申请大块内存；多线程管理方面是使用栈内存，每个线程有自己独立的栈内存进行管理。

golang内存分配器

golang内存分配器主要包含三个数据结构:MHeap,MCentral以及MCache

1.MHeap:分配堆，主要是负责向系统申请大块的内存，为下层MCentral和MCache提供内存服务。他管理的基本单位是MSpan(若干连续内存页的数据结构)

type MSpan struct

{

MSpan   *next;

MSpan   *prev;

PageId  start;  // 开始的页号

uintptr   npages; // 页数

…..

};

可以看出MSpan是一个双端链表的形式，里面存储了它的一些位置信息。

通过一个基地址+(页号*页大小)，就可以定位到这个MSpan的实际内存空间。

type MHeap struct

{

lock  mutex;

free  [_MaxMHeapList] mSpanList  // free lists of given length

freelarge mSpanList   // free lists length = _MaxMHeapList

busy  [_MaxMHeapList] mSpanList   // busy lists of large objects of given length

busylarge mSpanList

};

free数组以span为序号管理多个链表。当central需要时，只需从free找到页数合适的链表。large链表用于保存所有超出free和busy页数限制的MSpan。

MHeap示意图：

2.MCache:运行时分配池，不针对全局，而是每个线程都有自己的局部内存缓存MCache，他是实现goroutine高并发的重要因素，因为分配小对象可直接从MCache中分配，不用加锁，提升了并发效率。

type MCache struct

{

tiny   byte*;  // Allocator cache for tiny objects w/o pointers.

tinysize   uintptr;

alloc[NumSizeClasses] MSpan*;  // spans to allocate from

};

尽可能将微小对象组合到一个tiny块中，提高性能。

alloc[]用于分配对象，如果没有了，则可以向对应的MCentral获取新的Span进行操作。

线程中分配小对象(16~32K)的过程：

对于

size 介于 16 ~ 32K byte 的内存分配先计算应该分配的 sizeclass，然后去 mcache 里面

alloc[sizeclass] 申请，如果 mcache.alloc[sizeclass] 不足以申请，则 mcache 向 mcentral

申请mcentral 给 mcache 分配完之后会判断自己需不需要扩充，如果需要则想 mheap 申请。

每个线程内申请内存是逐级向上的，首先看MCache是否有足够空间，没有就像MCentral申请，再没有就像MHeap，MHeap向系统申请内存空间。

3.MCentral:作为MHeap和MCache的承上启下的连接。承上，从MHeap申请MSpan；启下，将MSpan划分为各种尺寸的对象提供给MCache使用。

type MCentral struct

{

lock mutex;

sizeClass int32;

noempty mSpanList;

empty mSpanList;

int32 nfree;

……

};

type mSpanList struct {

first *mSpan

last  *mSpan

};

sizeclass: 也有成员 sizeclass，用于将MSpan进行切分。

lock: 因为会有多个 P 过来竞争。

nonempty: mspan 的双向链表，当前 mcentral 中可用的 mSpan list。

empty: 已经被使用的，可以认为是一种对所有 mSpan 的 track。MCentral存在于MHeap内。

给对象 object 分配内存的主要流程：

1.object size 32K，则使用 mheap 直接分配。

2.object size 16 byte，使用 mcache 的小对象分配器 tiny 直接分配。 （其实 tiny 就是一个指针，暂且这么说吧。）

3.object size 16 byte size =32K byte 时，先使用 mcache 中对应的 size class 分配。

4.如果 mcache 对应的 size class 的 span 已经没有可用的块，则向 mcentral 请求。

5.如果 mcentral 也没有可用的块，则向 mheap 申请，并切分。

6.如果 mheap 也没有合适的 span，则想操作系统申请。

tcmalloc内存分配器介绍

tcmalloc(thread-caching mallo)是google推出的一种内存分配器。

具体策略：全局缓存堆和进程的私有缓存。

1.对于一些小容量的内存申请试用进程的私有缓存，私有缓存不足的时候可以再从全局缓存申请一部分作为私有缓存。

2.对于大容量的内存申请则需要从全局缓存中进行申请。而大小容量的边界就是32k。缓存的组织方式是一个单链表数组，数组的每个元素是一个单链表，链表中的每个元素具有相同的大小。

golang语言中MHeap就是全局缓存堆，MCache作为线程私有缓存。

在文章开头说过，内存池就是利用MHeap实现，大小切分则是在申请内存的时候就做了，同时MCache分配内存时，可以用MCentral去取对应的sizeClass，多线程管理方面则是通过MCache去实现。

总结:

1.MHeap是一个全局变量，负责向系统申请内存，mallocinit()函数进行初始化。如果分配内存对象大于32K直接向MHeap申请。

2.MCache线程级别管理内存池，关联结构体P，主要是负责线程内部内存申请。

3.MCentral连接MHeap与MCache的，MCache内存不够则向MCentral申请，MCentral不够时向MHeap申请内存。

（十一）golang 内存分析

编写过C语言程序的肯定知道通过malloc()方法动态申请内存，其中内存分配器使用的是glibc提供的ptmalloc2。 除了glibc，业界比较出名的内存分配器有Google的tcmalloc和Facebook的jemalloc。二者在避免内存碎片和性能上均比glic有比较大的优势，在多线程环境中效果更明显。

Golang中也实现了内存分配器，原理与tcmalloc类似，简单的说就是维护一块大的全局内存，每个线程(Golang中为P)维护一块小的私有内存，私有内存不足再从全局申请。另外，内存分配与GC（垃圾回收）关系密切，所以了解GC前有必要了解内存分配的原理。

为了方便自主管理内存，做法便是先向系统申请一块内存，然后将内存切割成小块，通过一定的内存分配算法管理内存。 以64位系统为例，Golang程序启动时会向系统申请的内存如下图所示：

预申请的内存划分为spans、bitmap、arena三部分。其中arena即为所谓的堆区，应用中需要的内存从这里分配。其中spans和bitmap是为了管理arena区而存在的。

arena的大小为512G，为了方便管理把arena区域划分成一个个的page，每个page为8KB,一共有512GB/8KB个页；

spans区域存放span的指针，每个指针对应一个page，所以span区域的大小为(512GB/8KB)乘以指针大小8byte = 512M

bitmap区域大小也是通过arena计算出来，不过主要用于GC。

span是用于管理arena页的关键数据结构，每个span中包含1个或多个连续页，为了满足小对象分配，span中的一页会划分更小的粒度，而对于大对象比如超过页大小，则通过多页实现。

根据对象大小，划分了一系列class，每个class都代表一个固定大小的对象，以及每个span的大小。如下表所示：

上表中每列含义如下：

class： class ID，每个span结构中都有一个class ID, 表示该span可处理的对象类型

bytes/obj：该class代表对象的字节数

bytes/span：每个span占用堆的字节数，也即页数乘以页大小

objects: 每个span可分配的对象个数，也即（bytes/spans）/（bytes/obj）waste

bytes: 每个span产生的内存碎片，也即（bytes/spans）%（bytes/obj）上表可见最大的对象是32K大小，超过32K大小的由特殊的class表示，该class ID为0，每个class只包含一个对象。

span是内存管理的基本单位,每个span用于管理特定的class对象, 跟据对象大小，span将一个或多个页拆分成多个块进行管理。src/runtime/mheap.go:mspan定义了其数据结构：

以class 10为例，span和管理的内存如下图所示：

spanclass为10，参照class表可得出npages=1,nelems=56,elemsize为144。其中startAddr是在span初始化时就指定了某个页的地址。allocBits指向一个位图，每位代表一个块是否被分配，本例中有两个块已经被分配，其allocCount也为2。next和prev用于将多个span链接起来，这有利于管理多个span，接下来会进行说明。

有了管理内存的基本单位span，还要有个数据结构来管理span，这个数据结构叫mcentral，各线程需要内存时从mcentral管理的span中申请内存，为了避免多线程申请内存时不断的加锁，Golang为每个线程分配了span的缓存，这个缓存即是cache。src/runtime/mcache.go:mcache定义了cache的数据结构

alloc为mspan的指针数组，数组大小为class总数的2倍。数组中每个元素代表了一种class类型的span列表，每种class类型都有两组span列表，第一组列表中所表示的对象中包含了指针，第二组列表中所表示的对象不含有指针，这么做是为了提高GC扫描性能，对于不包含指针的span列表，没必要去扫描。根据对象是否包含指针，将对象分为noscan和scan两类，其中noscan代表没有指针，而scan则代表有指针，需要GC进行扫描。mcache和span的对应关系如下图所示：

mchache在初始化时是没有任何span的，在使用过程中会动态的从central中获取并缓存下来，跟据使用情况，每种class的span个数也不相同。上图所示，class 0的span数比class1的要多，说明本线程中分配的小对象要多一些。

cache作为线程的私有资源为单个线程服务，而central则是全局资源，为多个线程服务，当某个线程内存不足时会向central申请，当某个线程释放内存时又会回收进central。src/runtime/mcentral.go:mcentral定义了central数据结构：

lock: 线程间互斥锁，防止多线程读写冲突

spanclass : 每个mcentral管理着一组有相同class的span列表

nonempty: 指还有内存可用的span列表

empty: 指没有内存可用的span列表

nmalloc: 指累计分配的对象个数线程从central获取span步骤如下：

将span归还步骤如下：

从mcentral数据结构可见，每个mcentral对象只管理特定的class规格的span。事实上每种class都会对应一个mcentral,这个mcentral的集合存放于mheap数据结构中。src/runtime/mheap.go:mheap定义了heap的数据结构：

lock： 互斥锁

spans: 指向spans区域，用于映射span和page的关系

bitmap：bitmap的起始地址

arena_start: arena区域首地址

arena_used: 当前arena已使用区域的最大地址

central: 每种class对应的两个mcentral

从数据结构可见，mheap管理着全部的内存，事实上Golang就是通过一个mheap类型的全局变量进行内存管理的。mheap内存管理示意图如下：

系统预分配的内存分为spans、bitmap、arean三个区域，通过mheap管理起来。接下来看内存分配过程。

针对待分配对象的大小不同有不同的分配逻辑：

(0, 16B) 且不包含指针的对象： Tiny分配

(0, 16B) 包含指针的对象：正常分配

[16B, 32KB] : 正常分配

(32KB, -) : 大对象分配其中Tiny分配和大对象分配都属于内存管理的优化范畴，这里暂时仅关注一般的分配方法。

以申请size为n的内存为例，分配步骤如下：

Golang内存分配是个相当复杂的过程，其中还掺杂了GC的处理，这里仅仅对其关键数据结构进行了说明，了解其原理而又不至于深陷实现细节。1、Golang程序启动时申请一大块内存并划分成spans、bitmap、arena区域

2、arena区域按页划分成一个个小块。

3、span管理一个或多个页。

4、mcentral管理多个span供线程申请使用

5、mcache作为线程私有资源，资源来源于mcentral。

升级mac后arduino出现如下编译问题，急求教！

一些用户反映在使用windows7系统电脑的时候发现无法正常驱动Arduino，而尝试在在MAC OS和Linux系统下，直接插上，即可使用。为什么 Windows7系统无法正常驱动Arduino呢?其实这种故障主要是因为需要为Arduino安装驱动配置文件的原因，需要为Arduino安装驱动配置文件，方可驱动Arduino，下面小编给大家介绍Windows7系统无法正常驱动Arduino的解决方案。

Windows7系统无法正常驱动Arduino的解决方案/步骤如下：

1、在Windows7系统中插上arduino，在电脑右下角就会显示“正在安装设备驱动程序软件” 。

2、但是过一会儿就会提示“未能成功安装设备驱动程序” ，因为找不到驱动。

3、此时右击“我的电脑”选择“属性”，进入“设备管理器”，会看到一个未知设备。

4、双击该未知设备，在弹出的未知设备属性的常规选项中选择“更新驱动程序”。

Windows7系统无法正常驱动Arduino怎么解决？

5、在弹出的“更新驱动程序-未知设备”窗口中选择第二项。

Windows7系统无法正常驱动Arduino怎么解决？