源碼啟動過程

㈠ 編寫java程序的時候，怎樣用源碼實現開機自啟動

通>常業界我們的做法有兩種，但是都不是你說的源碼實現，一種是bat文件放入開始->啟動中，另一種是將java程序做成exe文件並添加到服務裡面然後設置成開機啟動，下面簡單跟你介紹下兩種做法：
第一種
寫一個bat文件
java -jar xxx.jar
(注意路徑，java -jar 後面是你的可運行jar)
然後把bat放到開始-啟動裡面，windows啟動時會自動執行啟動裡面的程序。
第二種
1 把java程序轉換為exe文件，下載exe4j來轉換：過程比較簡單，選擇regular mode,excutable tyep 選擇GUI
Application,選擇其他會有問題，不能成功做成服務，按步驟生成yourApp.exe文件。
2 下載instsrv.exe和srvany.exe程序，這是win2000自帶的程序，在winxp中因為安全原因被去除，可以在網上下載到。
3 把兩個文件放置在與java的bin目錄下，運行 x:\bin\instsrv.exe yourApp x:\bin\srvany.exe
,yourApp是要建立的服務名。
4 yourApp服務已經建立起來了，打開注冊表，展開"HKEY_LOCAL_MACHINE\SYSTEM\currentcontrolset\services",找到yourApp
項，在該項下面新建一個名為"Parameters"的項目，接著在「Parameters」項下新建一個類型為字元串值的「application」子鍵，該鍵值為要執行的exe文件的磁碟全路徑。
5 運行中輸入"Services.msc"並回車或者直接打開服務，在列表中找到我們剛添加的yourApp 服務,把它設置為自動運行，程序會以服務的形式開機自動運行。

㈡ Spark源碼分析之SparkSubmit的流程

本文主要對SparkSubmit的任務提交流程源碼進行分析。 Spark源碼版本為2.3.1。

首先閱讀一下啟動腳本，看看首先載入的是哪個類，我們看一下 spark-submit 啟動腳本中的具體內容。

可以看到這里載入的類是org.apache.spark.deploy.SparkSubmit，並且把啟動相關的參數也帶過去了。下面我們跟一下源碼看看整個流程是如何運作的...

SparkSubmit的main方法如下

這里我們由於我們是提交作業，所有會走上面的submit(appArgs, uninitLog)方法

可以看到submit方法首先會准備任務提交的環境，調用了prepareSubmitEnvironment，該方法會返回四元組，該方法中會調用doPrepareSubmitEnvironment，這里我們重點注意 childMainClass類具體是什麼 ，因為這里涉及到後面啟動我們主類的過程。

以下是doPrepareSubmitEnvironment方法的源碼...

可以看到該方法首先是解析相關的參數，如jar包，mainClass的全限定名，系統配置，校驗一些參數，等等，之後的關鍵點就是根據我們 deploy-mode 參數來判斷是如何運行我們的mainClass，這里主要是通過childMainClass這個參數來決定下一步首先啟動哪個類。

childMainClass根據部署模型有不同的值:

之後該方法會把准備好的四元組返回，我們接著看之前的submit方法

可以看到這里最終會調用doRunMain()方法去進行下一步。

doRunMain的實現如下...

doRunMain方法中會判斷是否需要一個代理用戶，然後無論需不需要都會執行runMain方法，我們接下來看看runMain方法是如何實現的。

這里我們只假設以集群模式啟動，首先會載入類，將我們的childMainClass載入為位元組碼對象mainClass ，然後將mainClass 映射成SparkApplication對象，因為我們以集群模式啟動，那麼上一步返回四元組中的childMainClass的參數為ClientApp的全限定名，而這里會調用app實例的start方法因此，這里最終調用的是ClientApp的start方法。

ClientApp的start方法如下...

可以看到這里和之前我們的master啟動流程有些相似。
可以參考我上一篇文章 Spark源碼分析之Master的啟動流程 對這一流程加深理解。

首先是准備rpcEnv環境，之後通過master的地址獲取masterEndpoints端點相關信息，因為這里運行start方法時會將之前配置的相關參數都傳進來，之後就會通過rpcEnv注冊相關clientEndPoint端點信息，同時需要注意，這里會把masterEndpoints端點信息也作為構造ClientEndpoint端點的參數，也就是說這個ClientEndpoint會和masterEndpoints通信。

而在我上一篇文章中說過，只要是setupEndpoint方法被調用，一定會調用相關端點的的onStart方法，而這會調用clientEndPoint的onStart方法。

ClientEndPoint類中的onStart方法會匹配launch事件。源碼如下

onStart中匹配我們的launch的過程，這個過程是啟動driverWrapper的過程，可以看到上面源碼中封裝了mainClass ，該參數對應DriverWrapper類的全限定名，之後將mainClass封裝到command中，然後封裝到driverDescription中，向Master申請啟動Driver。

這個過程會向Mster發送消息，是通過rpcEnv來實現發射消息的，而這里就涉及到outbox信箱，會調用postToOutbox方法，向outbox信箱中添加消息，然後通過TransportClient的send或sendRpc方法發送消息。發件箱以及發送過程是在同一個線程中進行。

而細心的同學會注意到這里調用的方法名為SendToMasterAndForwardReply，見名之意，發送消息到master並且期待回應。

下面是rpcEnv來實現向遠端發送消息的一個調用流程，最終會通過netty中的TransportClient來寫出。

之後，Master端會觸發receiveAndReply函數,匹配RequestSubmitDriver樣例類，完成模式匹配執行後續流程。

可以看到這里首先將Driver信息封裝成DriverInfo，然後添加待調度列表waitingDrivers中，然後調用通用的schele函數。

由於waitingDrivers不為空，則會走LaunchDriver的流程，當前的application申請資源，這時會向worker發送消息，觸發Worker的receive方法。

Worker的receive方法中，當Worker遇到LaunchDriver指令時，創建並啟動一個DriverRunner，DriverRunner啟動一個線程，非同步的處理Driver啟動工作。這里說啟動的Driver就是剛才說的org.apache.spark.deploy.worker.DriverWrapper

可以看到上面在DriverRunner中是開辟線程非同步的處理Driver啟動工作，不會阻塞主進程的執行，而prepareAndRunDriver方法中最終調用 runDriver..

runDriver中主要先做了一些初始化工作，接著就開始啟動driver了。

上述Driver啟動工作主要分為以下幾步：

下面我們直接看DriverWrapper的實現

DriverWrapper，會創建了一個RpcEndpoint與RpcEnv，RpcEndpoint為WorkerWatcher，主要目的為監控Worker節點是否正常，如果出現異常就直接退出，然後當前的ClassLoader載入userJar，同時執行userMainClass，在執行用戶的main方法後關閉workerWatcher。

以上就是SparkSubmit的流程，下一篇我會對SparkContext的源碼進行解析。

歡迎關注...

㈢ [Spring boot源碼解析] 2 啟動流程分析

在了解 Spring Boot 的啟動流程的時候，我們先看一下一個Spring Boot 應用是如何啟動的，如下是一個簡單的 SpringBoot 程序，非常的簡潔，他是如何做到的呢，我們接下來就將一步步分解。

我們追蹤 SpringApplication.run() 方法，其實最終它主要的邏輯是新建一個 SpringApplication ，然後調用他的 run 方法，如下:

我們先來看一下創建 SpringApplication 的方法：

在將Main class 設置 primarySources 後，調用了 WebApplicationType.deceFromClasspath() 方法，該方法是為了檢查當前的應用類型，並設置給 webApplicationType 。 我們進入 deceFromClasspath 方法 ：

這里主要是通過類載入器判斷是否存在 REACTIVE 相關的類信息，假如有就代表是一個 REACTIVE 的應用，假如不是就檢查是否存在 Servelt 和 ，假如都沒有，就代表應用為非 WEB 類應用，返回 NONE ，默認返回 SERVLET 類型，我們這期以我們目前最常使用的 SERVLET 類型進行講解，所以我們在應用中引入了 spring-boot-starter-web 作為依賴：

他會包含 Spring-mvc 的依賴，所以就包含了內嵌 tomcat 中的 Servlet 和 Spring-web 中的 ,因此返回了 SERVLET 類型。

回到剛才創建 SpringApplication 的構建方法中，我們設置完成應用類型後，就尋找所有的 Initializer 實現類，並設置到 SpringApplication 的 Initializers 中，這里先說一下 getSpringFactoriesInstances 方法，我們知道在我們使用 SpringBoot 程序中，會經常在 META-INF/spring.factories 目錄下看到一些 EnableAutoConfiguration ，來出發 config 類注入到容器中，我們知道一般一個 config 類要想被 SpringBoot 掃描到需要使用 @CompnentScan 來掃描具體的路徑，對於 jar 包來說這無疑是非常不方便的，所以 SpringBoot 提供了另外一種方式來實現，就是使用 spring.factories ，比如下面這個，我們從 Springboot-test 中找到的例子，這里先定義了一個ExampleAutoConfiguration，並加上了 Configuration 註解：

然後在 spring.factories 中定義如下：

那這種方式是怎麼實現的你，這就要回到我們剛才的方法 getSpringFactoriesInstances :

我們先來看一下傳入參數，這里需要注意的是 args，這個是初始化對應 type 的時候傳入的構造參數，我們先看一下 SpringFactoriesLoader#loadFactoryNames 方法：

首先是會先檢查緩存，假如緩存中存在就直接返回，假如沒有就調用 classLoader#getResources 方法，傳入 META-INF/spring.factories ，即獲取所有 jar 包下的對應文件，並封裝成 UrlResource ，然後使用 PropertiesLoaderUtils 將這些信息讀取成一個對一對的 properties，我們觀察一下 spring.factories 都是按 properties 格式排版的，假如有多個就用逗號隔開，所以這里還需要將逗號的多個類分隔開來，並加到 result 中，由於 result 是一個 LinkedMultiValueMap 類型，支持多個值插入，最後放回緩存中。最終完成載入 META-INF/spring.factories 中的配置，如下：

我們可以看一下我們找到的 initializer 有多少個：

在獲取到所有的 Initializer 後接下來是調用 方法進行初始化。

這里的 names 就是我們上面通過類載入器載入到的類名，到這里會先通過反射生成 class 對象，然後判斷該類是否繼承與 ApplicationContextInitializer ，最後通過發射的方式獲取這個類的構造方法，並調用該構造方法，傳入已經定義好的構造參數，對於 ApplicationContextInitializer 是無參的構造方法，然後初始化實例並返回，回到原來的方法，這里會先對所有的 ApplicationContextInitializer 進行排序，調用 #sort(instances) 方法，這里就是根據 @Order 中的順序進行排序。

接下來是設置 ApplicationListener ，我們跟進去就會發現這里和上面獲取 ApplicationContextInitializer 的方法如出一轍，最終會載入到如圖的 15 個 listener （這里除了 外，其他都是 SpringBoot 內部的 Listener）:

在完成 SpringApplication 對象的初始化後，我們進入了他的 run 方法，這個方法幾乎涵蓋了 SpringBoot 生命周期的所有內容，主要分為九個步驟，每一個步驟這里都使用註解進行標識：

主要步驟如下：
第一步：獲取 SpringApplicationRunListener， 然後調用他的 staring 方法啟動監聽器。
第二步：根據 SpringApplicationRunListeners以及參數來准備環境。
第三步：創建 Spring 容器。
第四步：Spring 容器的前置處理。
第五步：刷新 Spring 容器。
第六步： Spring 容器的後置處理器。
第七步：通知所有 listener 結束啟動。
第八步：調用所有 runner 的 run 方法。
第九步：通知所有 listener running 事件。
我們接下來一一講解這些內容。

我們首先看一下第一步，獲取 SpringApplicationRunListener :

這里和上面獲取 initializer 和 listener 的方式基本一致，都是通過 getSpringFactoriesInstances , 最終只找到一個類就是： org.springframework.boot.context.event.EventPublishingRunListener ，然後調用其構造方法並傳入產生 args , 和 SpringApplication 本身:

我們先看一下構造函數，首先將我們獲取到的 ApplicationListener 集合添加到initialMulticaster 中， 最後都是通過操作 來進行廣播，我，他繼承於 ，我們先看一下他的 addApplicationListener 方法：

我們可以看出，最後是放到了 applicationListenters 這個容器中。他是 defaultRetriever 的成員屬性， defaultRetriever 則是 的私有類，我們簡單看一下這個類：

我們只需要看一下這里的 getApplicationListeners 方法，它主要是到 beanFactory 中檢查是否存在多的 ApplicationListener 和舊的 applicationListeners 組合並返回，接著執行 listener 的 start 方法，最後也是調用了 的 multicastEvent 查找支持對應的 ApplicationEvent 類型的通知的 ApplicationListener 的 onApplicationEvent 方法 ,這里除了會:

篩選的方法如下，都是調用了對應類型的 supportsEventType 方法 ：

如圖，我們可以看到對 org.springframework.boot.context.event.ApplicationStartingEvent 感興趣的有5個 Listener

環境准備的具體方法如下：

首先是調用 getOrCreateEnvironment 方法來創建 environment ，我們跟進去可以發現這里是根據我們上面設置的環境的類型來進行選擇的，當前環境會創建 StandardServletEnvironment

我們先來看一下 StandardServletEnvironment 的類繼承關系圖，我們可以看出他是繼承了 AbstractEnvironment ：

他會調用子類的 customizePropertySources 方法實現,首先是 StandardServletEnvironment 的實現如下，他會添加 servletConfigInitParams , servletContextInitParams , jndiProperties 三種 properties，當前調試環境沒有配置 jndi properties，所以這里不會添加。接著調用父類的 customizePropertySources 方法，即調用到了 StandardEnvironment 。

我們看一下 StandardEnvironment#customizePropertySources 方法，與上面的三個 properties 創建不同，這兩個是會進行賦值的，包括系統環境變數放入 systemEnvironment 中，jvm 先關參數放到 systemProperties 中：

這里會添加 systemEnvironment 和 systemProperties 這兩個 properties，最終拿到的 properties 數量如下 4個：

在創建完成 Environment 後，接下來就到了調用 configureEnvironment 方法：

我們先看一下 configurePropertySources 方法，這里主要分兩部分，首先是查詢當前是否存在 defaultProperties ，假如不為空就會添加到 environment 的 propertySources 中，接著是處理命令行參數，將命令行參數作為一個 CompositePropertySource 或則 添加到 environment 的 propertySources 裡面，

接著調用 ConfigurationPropertySources#attach 方法,他會先去 environment 中查找 configurationProperties , 假如尋找到了，先檢查 configurationProperties 和當前 environment 是否匹配，假如不相等，就先去除，最後添加 configurationProperties 並將其 sources 屬性設置進去。

回到我們的 prepareEnvironment 邏輯，下一步是通知觀察者，發送 事件，調用的是 SpringApplicationRunListeners#environmentPrepared 方法，最終回到了 #multicastEvent 方法，我們通過 debug 找到最後對這個時間感興趣的 Listener 如下：

其主要邏輯如下：

這個方法最後載入了 PropertySourceLoader , 這里主要是兩種，一個是用於 Properties 的，一個是用於 YAML 的如下：

其中 apply 方法主要是載入 defaultProperties ，假如已經存在，就進行替換，而替換的目標 PropertySource 就是 load 這里最後的一個 consumer 函數載入出來的，這里列一下主要做的事情：
1、載入系統中設置的所有的 Profile 。
2、遍歷所有的 Profile ，假如是默認的 Profile ， 就將這個 Profile 加到 environment 中。
3、調用load 方法，載入配置，我們深入看一下這個方法：

他會先調用 getSearchLocations 方法，載入所有的需要載入的路徑，最終有如下路徑：

其核心方法是遍歷所有的 propertySourceLoader ，也就是上面載入到兩種 propertySourceLoader ,最紅 loadForFileExtension 方法，載入配置文件，這里就不展開分析了，說一下主要的作用，因為每個 propertySourceLoader 都有自己可以載入的擴展名，默認擴展名有如下四個 properties, xml, yml, yaml，所以最終拿到文件名字，然後通過 - 拼接所有的真實的名字，然後加上路徑一起載入。

接下來，我們分析 BackgroundPreinitializer ,這個方法在接收 ApplicationPrepareEnvironment 事件的時候真正調用了這份方法：

1、 ConversionServiceInitializer 主要負責將包括 日期，貨幣等一些默認的轉換器注冊到 formatterRegistry 中。
2、 ValidationInitializer 創建 validation 的匹配器。
3、 MessageConverterInitializer 主要是添加了一些 http 的 Message Converter。
4、 JacksonInitializer 主要用於生成 xml 轉換器的。
接著回到我們將的主體方法， prepareEnvironment 在調用完成 listeners.environmentPrepared(environment) 方法後，調用 bindToSpringApplication(environment) 方法，將 environment 綁定到 SpirngApplication 中。
接著將 enviroment 轉化為 StandardEnvironment 對象。
最後將 configurationProperties 加入到 enviroment 中， configurationProperties 其實是將 environment 中其他的 PropertySource 重新包裝了一遍，並放到 environment 中，這里主要的作用是方便 進行解析。

它主要是檢查是否存在 spring.beaninfo.ignore 配置，這個配置的主要作用是設置 javaBean 的內省模式，所謂內省就是應用程序在 Runtime 的時候能檢查對象類型的能力，通常也可以稱作運行時類型檢查，區別於反射主要用於修改類屬性，內省主要用戶獲取類屬性。那麼我們什麼時候會使用到內省呢，java主要是通過內省工具 Introspector 來完成內省的工作，內省的結果通過一個 Beaninfo 對象返回，主要包括類的一些相關信息，而在 Spring中，主要是 BeanUtils#Properties 會使用到，Spring 對內省機制還進行了改進，有三種內省模式，如下圖中紅色框框的內容，默認情況下是使用 USE_ALL_BEANINFO。假如設置為true，就是改成第三中 IGNORE_ALL_BEANINFO

首先是檢查 Application的類型，然後獲取對應的 ApplicationContext 類，我們這里是獲取到了 org.springframework.boot.web.servlet.context. 接著調用 BeanUtils.instantiateClass(contextClass); 方法進行對象的初始化。

最終其實是調用了 的默認構造方法。我們看一下這個方法做了什麼事情。這里只是簡單的設置了一個 reader 和一個 scanner，作用於 bean 的掃描工作。

我們再來看一下這個類的繼承關系

這里獲取 ExceptionReporter 的方式主要還是和之前 Listener 的方式一致,通過 getSpringFactoriesInstances 來獲取所有的 SpringBootExceptionReporter 。

其主要方法執行如下：

㈣ Android 10.0 Activity的啟動流程

本文主要學習記錄，基於Android 10的源碼，有錯誤歡迎指正，主要目的是梳理流程圖。

以進程為單位的調用棧圖如下：

1.activity中的startActivity方法最終都會通過拿到ATSM的代理IActivityTaskManager調用的startActivity；

2.之後進入system server進程中的ATMS startActivity，ATMS 經過收集Intent信息，然後使用ActivityStackSupervisor.startSpecificActivityLocked，如果進程已經存在，則直接使用realStartActivityLocked，通過App的binder客戶端的代理ApplicationThread調用回到bindApplication，走入Activity的啟動流程；如果進程不存在則通過socket鏈接Zygote，請求fork新的進程；

3.App進程創建完成後，進程啟動會調用ActivityThread.main方法，初始化主線程Handler,接著走入attach方法，然後通過AMS的代理調用AMS的attachApplication方法，並將App進程的通信代理ApplicationThread傳入AMS；

4.AMS獲取到ATMS調用ApplicationThread的bindApplication回到App進程的ActivityThread.ApplicationThread.bindApplication方法中，然後使用Handler切換到主線程執行handleBindApplication，這里初始化了App的進程名字、時間，用戶的硬體配置，包括App的文件系統，創建了App的Context實例，Instrumentation實例，調用App的onCreate回調方法，同時告訴AMS APP初始化工作完畢；

5.AMS接著會調用ATMS的attachApplication，最後調用ClientLifecycleManager的scheleTransaction方法，通過App的Binder代理ApplicationThread回到ActivityThread；

6.進入ActivityThread.ApplicationThread.scheleTransaction方法之後就進入了Activity的onStart、onResume回調

創建進程之前的過程主要是AMS的內部信息收集的判斷的過程，下面主要看一下App進程啟動的源碼流程

從應用進程被創建開始，ActivityThread.main被執行

調用ActivityThread的attach方法，然後將activity和AMS通信的Binder代理IApplicationThread實例傳入AMS

接著進入AMS進程，ActivityManagerService.attachApplicationLocked

1.thread.bindApplication ：該方法主要講App進程的配置信息通過IApplicationThread Binder通信回傳到ActivityThread中

2.mAtmInternal.attachApplication ：mAtmInternal實際就是ActivityTaskManager的實例，通過LocalServices載入

那麼這里相當於走到了ActivityTaskManagerServer的attachApplication中

先看第一條：

注意：ActivityThread中存在於Binder通信的代理--》ApplicationThread extends IApplicationThread.Stub

ActivityThread--》ApplicationThread--》bindApplication

這里的bindApplication主要初始化了AppBindData，然後發送BIND_APPLICATION給APP的主線程BIND_APPLICATION，最後執行了handleBindApplication

handleBindApplication如下：

ActivityThread--》class H extends Handler

該方法主要在App進程中對App的一些硬體資源配置申請的屬性、App的文件夾等完成App基本信息的初始化

接著看第二條：mAtmInternal.attachApplication

mAtmInternal.attachApplication最終會調用mRootActivityContainer.attachApplication(wpc)

RootActivityContainer.attachApplication

接著調用ActivityStackSupervisor.realStartActivityLocked開始創建Activity

ActivityStackSupervisor.realStartActivityLocked

創建ClientLifecycleManager和ClientTransactionHandler來輔助管理Activity的生命周期

注意

clientTransaction.addCallback是LaunchActivityItem

lifecycleItem是ResumeActivityItem

ClientLifecycleManager.scheleTransaction最終會調用ClientTransaction的schele方法

那麼這個mClient是IApplicationThread的實例，那麼此時也就回到了ActivityThread的ApplicationThread中

ActivityThread的ApplicationThread中

因為ActivityThread繼承ClientTransactionHandler，所以到了ClientTransactionHandler中

通過Handler發送消息EXECUTE_TRANSACTION到H中

接著TransactionExecutor的execute方法

LaunchActivityItem.execute方法

client其實是在ActivityThread的實例，那麼就回到了ActivityThread的handleLaunchActivity

接著調用performLaunchActivity

在performLaunchActivity中，主要是載入App的資源包，然後創建了Activity的context實例，並創建了Activity的實例，接著調用activity.attach方法，attach執行完之後調用了onCreate方法。

activity.attach

activity.attach中主要

1.創建了PhoneWindow實例

2.設置了Window介面的監聽

3.初始化了成員變數，包括線程和WindowManager

到此Oncreate已經完成，那麼OnStart和OnResume去哪了？

TransactionExecutor的execute方法

之前們只分析了executeCallbacks，接著executeLifecycleState方法

TransactionExecutor的executeLifecycleState方法

cycleToPath：lifecycleItem即為ResumeActivityItem

第一點：

int finish = lifecycleItem.getTargetState()

lifecycleItem對應ResumeActivityItem，如下：

ResumeActivityItem的getTargetState方法

對應ActivityLifecycleItem中的枚舉類型：

第二點：ActivityClientRecord中的mLifecycleState，由於在前面已經執行了handleLaunchActivity所以mLifecycleState=1

對應ActivityLifecycleItem中的枚舉類型：

PRE_ON_CREATE = 0

所以final int star = 1

接著看getLifecyclePath，此時start=1，finish=3

那麼返回的IntArray就是2

接著看performLifecycleSequence

最終執行的是handleStartActivity所以最終走到了ActivityThread的handleResumeActivity

兩點：

調用activity.performStart

調用Instrumetation.callActivityOnPostCreate

performStart方法：

調用了Instrumentation.callActivityOnStart方法：

最終到了activity的onStart方法

第二點：Instrumentation.callActivityOnPostCreate

上面主要走了cycleToPath，接著ResumeActivityItem.execute

調用了handleResumeActivity方法

handleResumeActivity最終調用performResumeActivity

調用了Instrumentation.callActivityOnResume，

到了activity.onResume()方法

參考文章： https://blog.csdn.net/u011386173/article/details/87802765

㈤ C語言源程序到運行程序經過哪幾個步驟

1、預處理

在這一階段，源碼中的所有預處理語句得到處理，例如：#include語句所包含的文件內容替換掉語句本身，所有已定義的宏被展開。

根據#ifdef，#if等語句的條件是否成立取捨相應的部分，預處理之後源碼中不再包含任何預處理語句。

GCC預處理階段可以生成.i的文件，通過選項-E可以使編譯器在預處理結束時就停止編譯。例如：gcc -E -o hello.i hello.c

2、編譯

這一階段，編譯器對源碼進行詞法分析、語法分析、優化等操作，最後生成匯編代碼。這是整個過程中最重要的一步，因此也常把整個過程稱為編譯。

可以通過選項-S使GCC在進行完編譯後停止，生成.s的匯編程序。例如：gcc -S -o hello.s hello.c

3、匯編

這一階段使用匯編器對匯編代碼進行處理，生成機器語言代碼，保存在後綴為.o的目標文件中。

當程序由多個代碼文件構成時，每個文件都要先完成匯編工作，生成.o目標文件後，才能進入下一步的鏈接工作。

目標文件已經是最終程序的某一部分了，只是在鏈接之前還不能執行。可以通過-c選項生成目標文件：gcc -c -o hello.o hello.c

4、鏈接

經過匯編以後的機器代碼還不能直接運行。為了使操作系統能夠正確載入可執行文件，文件中必須包含固定格式的信息頭，還必須與系統提供的啟動代碼鏈接起來才能正常運行，這些工作都是由鏈接器來完成的。gcc -o hello hello.c

5、運行：執行.EXE文件，得到運行結果。

㈥ Gin 的啟動過程、路由及上下文源碼解讀

Engine 是 gin 框架的一個實例，它包含了多路復用器、中間件和配置中心。

gin 通過 Engine.Run(addr ...string) 來啟動服務，最終調用的是 http.ListenAndServe(address, engine) ，其中第二個參數應當是一個 Handler 介面的實現，即 engine 實現了此介面：

Engine.ServeHTTP() 會先初始化一個空的上下文，然後掛上請求 c.Reuqest = req ，隨後執行 engine.handlerHTTPRequest(c) （包含主要處理邏輯的函數）。

以上就是正常處理一個請求的主要邏輯，其他的就現階段來說先忽略了。

Engine 組合了 RouterGroup。

RouterGroup 實現了 IRouter 介面，IRouter 介面是 IRoutes 介面和 Group 函數組合而成。

RouterGroup 的結構體只有四個屬性：

當新建 Engine 時，會初始化一個 RouterGroup 結構，RouterGroup 是組合在 Engine 中的（所以 Engine 可以調用 RouterGroup 的所有方法），同時 Engine 的引用也記錄在了 RouterGroup 上。

如上，RouterGroup 實現了 IRouter 介面，下面是一些方法的實現。

gin 通過上方 RouterGroup 暴露的幾個方法添加路由，底層使用的方法是 Engine.addRoute(method, path string, handlers HandlerChain) 。

Engine.trees 屬性是存儲所有路由信息的總入口。它是一個切片，其中每個元素對應一種 method 並且是一個多叉樹的根節點。

當 addRoute 時，先根據 method 找到對應的 tree （Engine.trees[i]）。然後會比較 加入者 的 path 和 node 中的 path 相似的部分， 相似的部分 作為 父結點，不同的部分作為 子結點。以 多叉樹 的方式存儲下來。

這里會把 URL 中的路由變數也當作字元串存入樹中，因為相同 URL 他們的變數也是一樣的。

當請求進來時，因為 Engine 實現了 Handler 介面，所以最後會調用到 Engine.ServeHTTP 內。

找路徑在

root.getValue() 比較復雜，這里就不多解釋了。

[email protected] context.go

Context 中定義了一些屬性和方法，用於擴展一些功能。

可以看到，這些方法主要用來獲取 gin 自身 Context 的一些信息。

Context 中保存了所有 handlers 列表，存在 Context.handlers 數組中，並用下標 Context.index 標記當前執行的位置。
當主動取消調用鏈時，會將 index 設置成一個最大值 63（ math.MaxInt8 / 2 ），也即調用鏈最大支持 64 個函數。
Context 中還提供了其他一些函數，當取消調用鏈的時候，可以設置請求返回的狀態碼和返回數據信息等。

Context 中的 httpWriter 整理一下。

gin 在 Context 中定義了錯誤信息欄位 Context.Errors 切片，可以鏈式存儲錯誤信息。

Go 原生的 Context 是通過 ValueContext 來存儲元數據信息的，每個 ValueContext 只能存儲一對信息，存儲多個信息對需要將許多 ValueContext 組成鏈條，讀寫很不高效。
gin 的 Context 中存的元數據數據是存在 Context.Keys map[string]interface{} 屬性中的，比起原生的 Context 使用起來會更高效。

是指用在 URL 路徑中設置的參數，如 /user/:id 的 id 參數。
存儲在 Context.Params 屬性中，其本質是一個切片，每一個元素是一個 K/V 元組。
因此，在 URL 中是可以使用重復的變數名的（如 /test/:id/case/:id ），但獲取值就需要自己從屬性中獲取了（如： c.Params[0] ）。

Query 類是用在 URL 後的參數部分（如： ?id=1 ）。

gin 通過 Context.queryCache 屬性存儲 query 參數，在調用獲取 Query 參數時以懶載入的方式初始化： c.queryCache = c.Request.URL.Query() 。

需要注意的是它也支持傳入 map 和 array，map 的傳入需要像這樣 ?m[k1]=v1&m[k2]=v2 ，array 的傳入像這樣 ?a=1&a=2 。

包含 PostForm、FormFile、MultipartForm 等。
先略

gin 為方便使用，通過綁定引擎設置了自動綁定用戶輸入和結構數據的方法。

這里包含設置狀態碼、設置響應頭以及等信息。

只說一些值得注意的

這些方法除了 .Value() 方法外，其他都是返回的默認空值，略。