這一次搞懂SpringMVC原理
@前端
前言
前面幾篇文章，學習了Spring IOC、Bean實例化過程、AOP、事務的源碼和設計思想，瞭解了Spring的總體運行流程，但若是是web開發，那麼必不可少的還有Spring MVC，本篇主要分析在請求調用過程當中SpringMVC的實現原理，經過本篇要搞懂它是怎麼解決請求、參數、返回值映射等問題的。java
正文
請求入口
咱們都知道前端調用後端接口時，都會經過Servlet進行轉發，而Servlet的聲明週期包含下面四個階段：ios
- 實例化（new）
- 初始化（init）
- 執行（service調用doGet/doPost）
- 銷燬（destroy）
前兩個階段在Spring啓動階段就作好了（init根據配置多是第一次請求時纔會調用），銷燬是服務關閉的時候進行，本文主要分析的就是請求執行階段。咱們知道SpringMVC的核心就是DispatcherServlet，該類是對Servlet的擴展，因此直接從該類的service方法開始，但在此類中沒有service方法，那確定是在其父類中，咱們先來看看其繼承體系：
逐個往上找，在FrameworkServlet方法中就有一個service方法：web
protected void service(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
HttpMethod httpMethod = HttpMethod.resolve(request.getMethod());
if (httpMethod == HttpMethod.PATCH || httpMethod == null) {
processRequest(request, response);
}
else {
super.service(request, response);
}
}
protected void service(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
{
String method = req.getMethod();
if (method.equals(METHOD_GET)) {
long lastModified = getLastModified(req);
if (lastModified == -1) {
doGet(req, resp);
} else {
long ifModifiedSince = req.getDateHeader(HEADER_IFMODSINCE);
if (ifModifiedSince < lastModified) {
maybeSetLastModified(resp, lastModified);
doGet(req, resp);
} else {
resp.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
}
}
} else if (method.equals(METHOD_HEAD)) {
long lastModified = getLastModified(req);
maybeSetLastModified(resp, lastModified);
doHead(req, resp);
} else if (method.equals(METHOD_POST)) {
doPost(req, resp);
} else if (method.equals(METHOD_PUT)) {
doPut(req, resp);
} else if (method.equals(METHOD_DELETE)) {
doDelete(req, resp);
} else if (method.equals(METHOD_OPTIONS)) {
doOptions(req,resp);
} else if (method.equals(METHOD_TRACE)) {
doTrace(req,resp);
} else {
String errMsg = lStrings.getString("http.method_not_implemented");
Object[] errArgs = new Object[1];
errArgs[0] = method;
errMsg = MessageFormat.format(errMsg, errArgs);
resp.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED, errMsg);
}
}
但其主要仍是調用父類HttpServlet中的方法，而該類又會根據不一樣的請求方式會調到子類中，最後的核心方法就是DispatcherServlet中的doDispatch方法：spring
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
HttpServletRequest processedRequest = request;
HandlerExecutionChain mappedHandler = null;
boolean multipartRequestParsed = false;
//異步管理
WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
try {
ModelAndView mv = null;
Exception dispatchException = null;
try {
//文件上傳
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);
//這個方法很重要，重點看
// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null) {
noHandlerFound(processedRequest, response);
return;
}
//獲取跟HandlerMethod匹配的HandlerAdapter對象
// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Process last-modified header, if supported by the handler.
String method = request.getMethod();
boolean isGet = "GET".equals(method);
if (isGet || "HEAD".equals(method)) {
long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
return;
}
}
//前置過濾器，若是爲false則直接返回
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
return;
}
//調用到Controller具體方法，核心方法調用，重點看看
// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
if (asyncManager.isConcurrentHandlingStarted()) {
return;
}
applyDefaultViewName(processedRequest, mv);
//中置過濾器
mappedHandler.applyPostHandle(processedRequest, response, mv);
}
catch (Exception ex) {
dispatchException = ex;
}
catch (Throwable err) {
// As of 4.3, we're processing Errors thrown from handler methods as well,
// making them available for @ExceptionHandler methods and other scenarios.
dispatchException = new NestedServletException("Handler dispatch failed", err);
}
//視圖渲染及後置過濾器執行
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
catch (Exception ex) {
triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
}
catch (Throwable err) {
triggerAfterCompletion(processedRequest, response, mappedHandler,
new NestedServletException("Handler processing failed", err));
}
finally {
if (asyncManager.isConcurrentHandlingStarted()) {
// Instead of postHandle and afterCompletion
if (mappedHandler != null) {
mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
}
}
else {
// Clean up any resources used by a multipart request.
if (multipartRequestParsed) {
cleanupMultipart(processedRequest);
}
}
}
}
MVC的全部處理邏輯都在這個方法中，先總結一下這個方法的實現邏輯，首先根據請求的url拿到緩存中的HandlerMethod對象和執行鏈對象，HandlerMethod中封裝了controller對象、方法對象和方法參數等信息，執行鏈則是包含了一個個HandlerInterceptor攔截器；而後再經過HandlerMethod拿到對應的HandlerAdapter，這個對象的做用就是去適配咱們的controller；準備工做作完後，首先會執行前置過濾，若是被攔截則直接返回，不然就去調用controller中的方法執行咱們的業務邏輯並返回一個ModelView對象；接着執行中置過濾器，以及處理全局異常捕獲器捕獲到異常；最後進行視圖渲染返回並執行後置過濾器進行資源釋放等工做。
以上就是MVC的總體執行流程，下面就逐個來分析，首先進入getHandler方法：後端
protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
//handlerMappering實例
if (this.handlerMappings != null) {
for (HandlerMapping mapping : this.handlerMappings) {
//獲取HandlerMethod和過濾器鏈的包裝類
HandlerExecutionChain handler = mapping.getHandler(request);
if (handler != null) {
return handler;
}
}
}
return null;
}
是委託給HandlerMapping對象的，這是一個接口，主要的實現類是RequestMappingHandlerMapping，一樣先來看看其繼承體系：
這個類是管理請求和處理類之間的映射關係的，你是否疑惑它是在哪裏實例化的呢？下面先來看看MVC組件的初始化。設計模式
組件初始化
這裏我以自動化配置的註解方式說明，Spring提供了一個@EnableWebMvc，經過前面的學習咱們知道在這個註解中一定導入了一個配置類，點進去能夠看到是DelegatingWebMvcConfiguration，這個類就是負責MVC的組件和擴展實現的初始化，其自己咱們先不看，先看其父類WebMvcConfigurationSupport，這個類咱們應該不陌生，要作一些自定義擴展時就須要繼承該類（如攔截器Interceptor），一樣做用的類還有WebMvcConfigurerAdapter，這個類是對前者相對安全的擴展，爲何是相對安全呢？由於繼承前者會致使自動配置失效，而使用後者則沒必要擔憂此問題，只須要在類上加上@EnableWebMvc註解。
在WebMvcConfigurationSupport中咱們能夠看到不少@Bean標註的方法，也就是mvc組件的實例化，這裏主要看看requestMappingHandlerMapping，其他的可自行閱讀理解，也就是一些Bean的註冊：跨域
public RequestMappingHandlerMapping requestMappingHandlerMapping() {
RequestMappingHandlerMapping mapping = createRequestMappingHandlerMapping();
mapping.setOrder(0);
mapping.setInterceptors(getInterceptors());
mapping.setContentNegotiationManager(mvcContentNegotiationManager());
mapping.setCorsConfigurations(getCorsConfigurations());
......省略
return mapping;
}
這裏主要看getInterceptors方法如何獲取攔截器的：數組
protected final Object[] getInterceptors() {
if (this.interceptors == null) {
InterceptorRegistry registry = new InterceptorRegistry();
//鉤子方法，須要本身定義
addInterceptors(registry);
registry.addInterceptor(new ConversionServiceExposingInterceptor(mvcConversionService()));
registry.addInterceptor(new ResourceUrlProviderExposingInterceptor(mvcResourceUrlProvider()));
this.interceptors = registry.getInterceptors();
}
return this.interceptors.toArray();
}
第一次進來會調用addInterceptors添加攔截器，這是一個模板方法，在子類DelegatingWebMvcConfiguration中實現：緩存
private final WebMvcConfigurerComposite configurers = new WebMvcConfigurerComposite();
protected void addInterceptors(InterceptorRegistry registry) {
this.configurers.addInterceptors(registry);
}
public void addInterceptors(InterceptorRegistry registry) {
for (WebMvcConfigurer delegate : this.delegates) {
delegate.addInterceptors(registry);
}
}
能夠看到最終是調用WebMvcConfigurer的addInterceptors方法，也就是咱們對WebMvcConfigurerAdapter的自定義擴展。看到這裏咱們應該明白了MVC的組件是如何添加到IOC容器中的，可是DispatcherServlet又是怎麼獲取到它們的呢？回到以前的代碼中，在DispatcherServlet這個類中有一個onRefresh方法，這個方法又調用了initStrategies方法完成了MVC九大組件的註冊：
protected void onRefresh(ApplicationContext context) {
initStrategies(context);
}
protected void initStrategies(ApplicationContext context) {
initMultipartResolver(context);
initLocaleResolver(context);
initThemeResolver(context);
initHandlerMappings(context);
initHandlerAdapters(context);
initHandlerExceptionResolvers(context);
initRequestToViewNameTranslator(context);
initViewResolvers(context);
initFlashMapManager(context);
}
private void initHandlerMappings(ApplicationContext context) {
this.handlerMappings = null;
if (this.detectAllHandlerMappings) {
// Find all HandlerMappings in the ApplicationContext, including ancestor contexts.
Map<String, HandlerMapping> matchingBeans =
BeanFactoryUtils.beansOfTypeIncludingAncestors(context, HandlerMapping.class, true, false);
if (!matchingBeans.isEmpty()) {
this.handlerMappings = new ArrayList<>(matchingBeans.values());
// We keep HandlerMappings in sorted order.
AnnotationAwareOrderComparator.sort(this.handlerMappings);
}
}
else {
try {
HandlerMapping hm = context.getBean(HANDLER_MAPPING_BEAN_NAME, HandlerMapping.class);
this.handlerMappings = Collections.singletonList(hm);
}
catch (NoSuchBeanDefinitionException ex) {
// Ignore, we'll add a default HandlerMapping later.
}
}
if (this.handlerMappings == null) {
this.handlerMappings = getDefaultStrategies(context, HandlerMapping.class);
}
}
以initHandlerMappings爲例，其它組件實現邏輯基本同樣。首先從IOC容器中拿到handlerMappings的全部實現類（WebMvcConfigurationSupport中注入的對象就在這裏被獲取到），若沒有，則從DispatcherServlet.properties配置文件中（這個配置在spring-webmvc工程下org/springframework/web/servlet/DispatcherServlet.properties）獲取默認的配置：
org.springframework.web.servlet.LocaleResolver=org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver org.springframework.web.servlet.ThemeResolver=org.springframework.web.servlet.theme.FixedThemeResolver org.springframework.web.servlet.HandlerMapping=org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping,\ org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping org.springframework.web.servlet.HandlerAdapter=org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\ org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\ org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter org.springframework.web.servlet.HandlerExceptionResolver=org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver,\ org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver,\ org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver org.springframework.web.servlet.RequestToViewNameTranslator=org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator org.springframework.web.servlet.ViewResolver=org.springframework.web.servlet.view.InternalResourceViewResolver org.springframework.web.servlet.FlashMapManager=org.springframework.web.servlet.support.SessionFlashMapManager
可是onRefresh又是在何時調用的呢？有兩個地方，一個是Servlet初始化時會調用到initWebApplicationContext進行容器的初始化，這個方法中就會觸發onRefresh；另外還有一個，在FrameworkServlet中有一個onApplicationEvent方法，而這個方法又會被內部類ContextRefreshListener調用，這個類實現了ApplicationListener接口，表示會接收容器刷新事件。
以上就就是MVC HandlerMapping組件的初始化邏輯，其它組件實現邏輯相同，下面再也不分析。
調用Controller
回到getHandler方法，其調用的是AbstractHandlerMapping類的方法：
public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
//根據請求的uri拿到對應的HandlerMethod對象
Object handler = getHandlerInternal(request);
if (handler == null) {
handler = getDefaultHandler();
}
if (handler == null) {
return null;
}
// Bean name or resolved handler?
if (handler instanceof String) {
String handlerName = (String) handler;
handler = obtainApplicationContext().getBean(handlerName);
}
//獲取HandlerMethod和過濾器鏈的包裝類
HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request);
if (logger.isTraceEnabled()) {
logger.trace("Mapped to " + handler);
}
else if (logger.isDebugEnabled() && !request.getDispatcherType().equals(DispatcherType.ASYNC)) {
logger.debug("Mapped to " + executionChain.getHandler());
}
//是不是跨域請求,就是查看request請求頭中是否有Origin屬性
if (CorsUtils.isCorsRequest(request)) {
//自定義的鉤子方法獲取跨域配置
CorsConfiguration globalConfig = this.corsConfigurationSource.getCorsConfiguration(request);
//註解獲取跨域配置
CorsConfiguration handlerConfig = getCorsConfiguration(handler, request);
CorsConfiguration config = (globalConfig != null ? globalConfig.combine(handlerConfig) : handlerConfig);
//這裏設置了跨域的過濾器CorsInterceptor
executionChain = getCorsHandlerExecutionChain(request, executionChain, config);
}
return executionChain;
}
先看AbstractHandlerMethodMapping.getHandlerInternal：
protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {
//從request對象中獲取uri，/common/query2
String lookupPath = getUrlPathHelper().getLookupPathForRequest(request);
this.mappingRegistry.acquireReadLock();
try {
//根據uri從映射關係中找到對應的HandlerMethod對象
HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request);
//把Controller類實例化
return (handlerMethod != null ? handlerMethod.createWithResolvedBean() : null);
}
finally {
this.mappingRegistry.releaseReadLock();
}
}
protected HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception {
List<Match> matches = new ArrayList<>();
// 根據url拿到對應的RequestMappingInfo
List<T> directPathMatches = this.mappingRegistry.getMappingsByUrl(lookupPath);
if (directPathMatches != null) {
addMatchingMappings(directPathMatches, matches, request);
}
if (matches.isEmpty()) {
// No choice but to go through all mappings...
addMatchingMappings(this.mappingRegistry.getMappings().keySet(), matches, request);
}
if (!matches.isEmpty()) {
Comparator<Match> comparator = new MatchComparator(getMappingComparator(request));
matches.sort(comparator);
Match bestMatch = matches.get(0);
if (matches.size() > 1) {
if (logger.isTraceEnabled()) {
logger.trace(matches.size() + " matching mappings: " + matches);
}
if (CorsUtils.isPreFlightRequest(request)) {
return PREFLIGHT_AMBIGUOUS_MATCH;
}
Match secondBestMatch = matches.get(1);
//若是兩個RequestMappinginfo什麼都相同，報錯
if (comparator.compare(bestMatch, secondBestMatch) == 0) {
Method m1 = bestMatch.handlerMethod.getMethod();
Method m2 = secondBestMatch.handlerMethod.getMethod();
String uri = request.getRequestURI();
throw new IllegalStateException(
"Ambiguous handler methods mapped for '" + uri + "': {" + m1 + ", " + m2 + "}");
}
}
request.setAttribute(BEST_MATCHING_HANDLER_ATTRIBUTE, bestMatch.handlerMethod);
handleMatch(bestMatch.mapping, lookupPath, request);
return bestMatch.handlerMethod;
}
else {
return handleNoMatch(this.mappingRegistry.getMappings().keySet(), lookupPath, request);
}
}
private void addMatchingMappings(Collection<T> mappings, List<Match> matches, HttpServletRequest request) {
for (T mapping : mappings) {
// 拿到匹配的RequestMappingInfo對象，有可能url相同，@RequestMapping的屬性（請求方式、參數等）匹配不上
T match = getMatchingMapping(mapping, request);
if (match != null) {
//RequestMappingInfo對象和HandlerMethod對象封裝到Match對象中，其實就是註解屬性和Method對象的映射
matches.add(new Match(match, this.mappingRegistry.getMappings().get(mapping)));
}
}
}
這裏邏輯很簡單，就是經過請求url從urlLookup中拿到對應的RequestMappingInfo（每個 @RequestMapping對應一個RequestMappingInfo對象）對象，再根據RequestMappingInfo對象從mappingLookup拿到對應的HandlerMethod並返回。
但這裏你可能會比較好奇urlLookup和mappingLookup從哪裏來的，仔細觀察你會發現當前這個類實現了一個接口InitializingBean，實現了這個接口的類會在該類的Bean實例化完成後調用afterPropertiesSet方法，上面的映射關係就是在這個方法中作的。實際上這個方法不止完成了上面兩個映射關係，還有下面兩個：
- corsLookup：handlerMethod -> corsConfig
- registry：RequestMappingInfo -> MappingRegistration（包含url、handlerMethod、RequestMappingInfo、name等信息）
這裏就不展開分析了，奉上一張時序圖，讀者可根據下面的時序圖自行分析：
拿到HandlerMethod對象後，又會經過getHandlerExecutionChain方法去獲取到全部的HandlerInterceptor攔截器對象，並連同HandlerMethod對象一塊兒封裝爲HandlerExecutionChain。以後是獲取跨域配置，這裏不詳細分析。
拿到HandlerExecutionChain對象後返回到doDispatch方法，又調用了getHandlerAdapter
方法拿到HandlerAdapter：
protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {
//根據handlerMethod對象，找到合適的HandlerAdapter對象，這裏用到了策略模式
if (this.handlerAdapters != null) {
for (HandlerAdapter adapter : this.handlerAdapters) {
if (adapter.supports(handler)) {
return adapter;
}
}
}
}
這裏的handlerAdapters變量值從哪裏來？相信不用我再分析，主要看這裏的設計思想，典型的策略模式。
以後調用完前置過濾器後，纔是真正調用咱們controller方法的邏輯，經過HandlerAdapter.handle去調用，最終會調用到ServletInvocableHandlerMethod.invokeAndHandle：
public void invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer,
Object... providedArgs) throws Exception {
//具體調用邏輯，重點看
Object returnValue = invokeForRequest(webRequest, mavContainer, providedArgs);
setResponseStatus(webRequest);
if (returnValue == null) {
if (isRequestNotModified(webRequest) || getResponseStatus() != null || mavContainer.isRequestHandled()) {
mavContainer.setRequestHandled(true);
return;
}
}
else if (StringUtils.hasText(getResponseStatusReason())) {
mavContainer.setRequestHandled(true);
return;
}
mavContainer.setRequestHandled(false);
Assert.state(this.returnValueHandlers != null, "No return value handlers");
try {
//返回值處理
this.returnValueHandlers.handleReturnValue(
returnValue, getReturnValueType(returnValue), mavContainer, webRequest);
}
catch (Exception ex) {
if (logger.isTraceEnabled()) {
logger.trace(formatErrorForReturnValue(returnValue), ex);
}
throw ex;
}
}
這個方法裏面主要看invokeForRequest和handleReturnValue的調用，前者是完成參數綁定並調用controller，後者則是對返回值進行處理並封裝到ModelAndViewContainer中。先來看invokeForRequest：
public Object invokeForRequest(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer,
Object... providedArgs) throws Exception {
//獲取參數數組
Object[] args = getMethodArgumentValues(request, mavContainer, providedArgs);
if (logger.isTraceEnabled()) {
logger.trace("Arguments: " + Arrays.toString(args));
}
return doInvoke(args);
}
doInvoke就是完成反射調用，主要仍是看參數綁定的實現邏輯，在getMethodArgumentValues方法中：
protected Object[] getMethodArgumentValues(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer,
Object... providedArgs) throws Exception {
if (ObjectUtils.isEmpty(getMethodParameters())) {
return EMPTY_ARGS;
}
//入參的包裝類，裏面包裝了參數類型，參數名稱，參數註解等等信息
MethodParameter[] parameters = getMethodParameters();
Object[] args = new Object[parameters.length];
for (int i = 0; i < parameters.length; i++) {
MethodParameter parameter = parameters[i];
//設置參數名稱解析器
parameter.initParameterNameDiscovery(this.parameterNameDiscoverer);
args[i] = findProvidedArgument(parameter, providedArgs);
if (args[i] != null) {
continue;
}
//典型的策略模式，根據parameter可否找到對應參數的處理類，能找到就返回true
if (!this.resolvers.supportsParameter(parameter)) {
throw new IllegalStateException(formatArgumentError(parameter, "No suitable resolver"));
}
try {
//具體參數值解析過程,重點看看
args[i] = this.resolvers.resolveArgument(parameter, mavContainer, request, this.dataBinderFactory);
}
catch (Exception ex) {
// Leave stack trace for later, exception may actually be resolved and handled..
if (logger.isDebugEnabled()) {
String error = ex.getMessage();
if (error != null && !error.contains(parameter.getExecutable().toGenericString())) {
logger.debug(formatArgumentError(parameter, error));
}
}
throw ex;
}
}
return args;
}
參數、返回值解析
由於參數類型很是多，同時還會伴隨各類註解，如：@RequestBody、@RequestParam、@PathVariable等，因此參數解析的工做是很是繁雜的，同時還要考慮到擴展性，因此SpringMVC依然採用了策略模式來完成對各類參數類型的解析綁定，其頂層接口就是HandlerMethodArgumentResolver，而默認SpringMVC提供的解析方式就高達20多種：
上面是類圖，讀者可根據本身熟悉的參數類型找到對應的類進行分析，最核心的仍是要掌握這裏的設計思想。
接着方法調用完成後就是對返回值的處理，一樣的，返回值類型也是很是多，也可使用各類註解標註，因此也是使用策略模式實現，其頂層接口是HandlerMethodReturnValueHandler，實現類以下：
調用完成以後就是執行後續操做了：執行中置過濾器、處理全局異常、視圖渲染以及執行後置過濾器，這些與主流程沒有太大關係，本篇不展開分析了，最後是MVC的執行時序圖：
總結
本篇是Spring核心原理系列的最後一篇，前先後後花了一個月時間，終於從宏觀上大體上理解了Spring的實現原理和運行機制，明白了以前項目中一些坑是如何產生的，最主要的是學到設計模式的運用以及如何利用Spring的一些經常使用的擴展點進行自定義擴展。但對於Spring這個龐大的體系來講，還有不少是要去理解學習的，尤爲是設計思想，只有長期琢磨才能深入的理解掌握。在我以前的文章中包括本篇還有不少沒分析到的細節，在後面我會不按期分享出來。
- 1. 這一次，完全搞懂SparseArray實現原理
- 2. 這一次，完全弄懂 Promise 原理
- 3. 這一次徹底搞懂 Git Rebase
- 4. 這一次完全搞懂 Git Rebase
- 5. 這一次，完全搞懂 Go Cond
- 6. 一文搞懂synchronized原理
- 7. 一篇文章搞懂SpringMVC核心執行原理
- 8. 這一次搞懂SpringBoot核心原理（自動配置、事件驅動、Condition）
- 9. 這一次搞懂Spring自定義標籤以及註解解析原理
- 10. 一次搞懂 Generator 函數
- 更多相關文章...
- • BASE原理與最終一致性 - NoSQL教程
- • MyBatis的工作原理 - MyBatis教程
- • ☆技術問答集錦（13）Java Instrument原理
- • Java Agent入門實戰（三）-JVM Attach原理與使用
-
每一个你不满意的现在，都有一个你没有努力的曾经。