錯誤信息:java.lang.StackOverflowError

關于這個錯誤的深度解析，大家可以參考這篇博文，比較詳細:https://blog.csdn.net/zc375039901/article/details/79179465\

先說說這個錯誤，我是怎么發生的？我的這個錯誤與上面我推薦的該錯誤原因深度解析沒有多大的關系，大家可以適當了解了解。

簡單的說，這是一個低級錯誤，特別對于"碼農"頭銜的大多數開發者而言。

習慣了慣性思維，習慣的復制粘貼，習慣了那套編寫業務邏輯層的方式。

貼代碼講示例:

錯誤代碼:

@Service public class SysModuleServiceImpl extends ServiceImpl<SysModuleDao, SysModule> implements SysModuleService {@Autowiredprivate SysModuleService sysModuleService;@Overridepublic List<SysModule> queryModuleListInfo(Map<String, Object> map) {// TODO Auto-generated method stubreturn sysModuleService.queryModuleListInfo(map);}@Overridepublic int queryModuleCountInfo(Map<String, Object> map) {// TODO Auto-generated method stubreturn sysModuleService.queryModuleCountInfo(map);}}

?

這是我一時疏忽，這樣寫了，其實也不能說是一時疏忽，只能說是思維定勢導致的。

開發者們一定不能思維定勢，對于思維定勢的開發者們，業界有這樣一句名言，做五年的開發，相當于一年而已或者是開發多年，還是在那一套章法上循環往復。

不多說大道理了，關于上面的代碼為什么不能這么寫，為什么是錯的,下面我將進行解答。

首先來說，@Service這個注解，大家應該不陌生了，特別是對于Java開發者們。

與這個注解并列的有@Reponsitory,@Component，@Controller,這些對于奮戰一線的開發者們，早已眼熟而詳了。

關于上面我為什么會犯這個錯誤？因為我忽略了依賴注入。

通常情況下，業務邏輯層直接與數據訪問層交互，而Dao層，早已通過MyBatis動態掃描，注入了也就是在對應的spring-mybatis.xml文件配置了Bean。

當然了，這里要提一點，之所以不用MyBatis非動態掃描的方式，最大的原因是難以維護，不方便管理，因為如果采用這種方式，每個對應的Dao，我都要專門寫一個bean進行管理，這樣非常不好。特別對于業務需求時常變化，甚至以后功能擴展，代碼重構都會帶來很大的麻煩。而采用動態掃描的方式，則只要在Spring-MyBatis.xml配置對應的如下所示即可，這里我用的是MyBatis Plus，MyBatis Plus和MyBatis同Spring整合，基本上是沒有區別的，除了一些特殊的插件和其他優化配置之外。

<!-- Spring整合Mybatis，更多查看文檔：http://mp.baomidou.com --><bean id="sqlSessionFactory" class="com.baomidou.mybatisplus.spring.MybatisSqlSessionFactoryBean"><property name="dataSource" ref="dataSource"/><!-- 自動掃描Mapping.xml文件 --><property name="mapperLocations" value="classpath:mybatis/system/*.xml"/><property name="configLocation" value="classpath:mybatis/mybatis-config.xml"/><property name="typeAliasesPackage" value="com.blog.entity"/><property name="plugins"><array><!-- 分頁插件配置 --><bean id="paginationInterceptor" class="com.baomidou.mybatisplus.plugins.PaginationInterceptor"></bean></array></property><!-- 全局配置注入 --><property name="globalConfig" ref="globalConfig" /></bean><bean id="globalConfig" class="com.baomidou.mybatisplus.entity.GlobalConfiguration"><!--AUTO->`0`("數據庫ID自增")INPUT->`1`(用戶輸入ID")ID_WORKER->`2`("全局唯一ID")UUID->`3`("全局唯一ID")--><property name="idType" value="2" /></bean><!-- MyBatis 動態掃描 --><bean class="org.mybatis.spring.mapper.MapperScannerConfigurer"><property name="basePackage" value="com.blog.daor"/></bean>

?

關鍵一行就是動態掃描這一行，還有就是對應的xml配置文件，上面和下面結合使Dao接口與xml文件中的sql進行綁定。

業務邏輯層是基于數據訪問層的，如果直接業務邏輯層按照我文章開頭那樣的錯誤代碼寫法，是無法訪問Dao層的。

另外大家要知道一點，層與層之間是雙向關系，數據訪問層依賴于數據庫，數據庫如果有什么異常，是會報錯的，業務邏輯層依賴于數據訪問層，控制層也就是接口層或者路由層，因為這里主要是處理前臺請求的，并根據對應的邏輯返回對應的數據或者某種提示信息等等。

?

正確代碼如下:

@Service public class SysModuleServiceImpl extends ServiceImpl<SysModuleDao, SysModule> implements SysModuleService {@Autowiredprivate SysModuleDao sysModuleDao;@Overridepublic List<SysModule> queryModuleListInfo(Map<String, Object> map) {// TODO Auto-generated method stubreturn sysModuleDao.queryModuleListInfo(map);}@Overridepublic int queryModuleCountInfo(Map<String, Object> map) {// TODO Auto-generated method stubreturn sysModuleDao.queryModuleCountInfo(map);}}

?

這里還要提一下，為什么要有業務邏輯層，簡單的說，業務邏輯層主要是為了復用數據訪問層，實際業務是非常復雜的，需要整合多個數據訪問層來達到實現業務的目的，比如拿智能門鎖來說，我需要知道門鎖編碼是否存在，之前是否批量導入，根據我們的業務，與我們合作商，購買我們的門鎖，通常購買一般以批次來衡量，比如他們購買了我們100把門鎖，我們在后臺通過一個Excel數據記錄對應的門鎖編號和其他相關數據，將其錄入到我們的數據表中(批量導入),然后對方使用我們的后臺管理系統進行安裝，雖然我們導入了但是尚未激活，門鎖有一個對應的狀態，默認為0(尚未安裝的或尚未激活的意思)。

當他們安裝時，首先需要判斷安裝門鎖編碼是否存在，另外他們用于住宿方面，酒店編號和房間編號是否存在(這里使用我們對應的智能酒店管理系統與智能門鎖后臺系統進行關聯，還有就是網關，判斷網關是否安裝，而且網關涉及到我們另外的數據表，為了使門鎖與網關結合，我們需要編寫一個方法，該方法涉及兩張表的業務方面，所以這里就需要業務邏輯層，這里我想表達的意思是，業務邏輯層就是為了更好的處理業務和復用業務，以此來達到構建一個可擴展性好，可維護性好，穩定性好的web系統。

?

小結:這里我想告訴大家的是，不要忽視任何一個錯誤以及對于編程人員而言，是用腦來思考編程如何做的更好，而不是慢慢的變為一個重復性的體力勞動。當然了，博主我目前也沒有完全做到，所以需要不斷的學習和實際中不斷的反思總結，以此來達到做最優秀的程序員和寫一手優雅的代碼目的。

轉載于:https://www.cnblogs.com/youcong/p/9451756.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的记一次MyBatis的错误的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。