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怎麼解決？