背景介紹
本人前陣子接了部門的一個小需求，公司新成立一個子公司，有個門戶網站需要java服務端支持一下，老大找打我，讓我花兩天時間搞定它。我找運營瞭解了下需求發現簡單不能再簡單，讓我搞畢業大學生就餓能做的事，不爽(但是事還得做啊)，瞭解到springboot近兩年很火(ps：項目原因之前沒用過springboot)，於是打算用springboot來做。
花了一上午時間簡單瞭解了下，別說搞個web項目是真快，遂一鼓作氣一下午搞定了所有需求，加了個班自測也過了（有別的棘手的事要忙，所以不能在這耽擱時間），覺得還可以，於是直接寫了文檔給前端了。
沒過多久，前端也完成，測試ok，上線了。
禍從天降
直到上週五，我被拉到一個wx群說文件上傳異常了，臥槽lz一臉懵逼，不是測試ok了嗎？神馬情況，我當時的第一反應：shit，掉坑裡了。於是我找運維小哥哥要了權限上去看了日誌，報錯日誌大概長這樣子：
org.springframework.web.multipart.MultipartException: Could not parse multipart servlet request; nested exception is java.io.IOException: The temporary upload location [/tmp/tomcat.1337767218595042057.80/work/Tomcat/localhost/ROOT] is not valid
認真看了下，還真不知道這說的啥玩意！ 也不想多浪費時間，於是google，瞭解到原因大致如下：在linux系統中，springboot應用服務再啟動（java -jar 命令啟動服務）的時候，會在操作系統的/tmp目錄下生成一個tomcat*的文件目錄，上傳的文件先要轉換成臨時文件保存在這個文件夾下面。由於臨時/tmp目錄下的文件，在長時間（10天）沒有使用的情況下，就會被系統機制自動刪除掉。所以如果系統長時間無人問津的話，就可能導致上面這個問題。
這下原因明白了，要我說這springboot也是有病，開發加測試也沒到10天，10天內根本測不出來問題，可能這貨有個好爸爸Spring吧。
既然出問題了，總要解決的，下面提供兩種方法，親測有效。
手動注入一個Bean,並配置臨時目錄
@Bean
MultipartConfigElement multipartConfigElement() {
MultipartConfigFactory factory = new MultipartConfigFactory();
factory.setLocation("/app/xxx/uploadtmp");
return factory.createMultipartConfig();
}
而我則採用下面這種方式，方便快捷
yml配置臨時目錄
yml配置文件上傳臨時目錄
server:
port: 19990
context-path: /appName
tomcat:
basedir: /app/xxx/uploadtmp
以上兩種方式配置後，都會在/app/xxx/uploadtmp目錄下生成一堆文件，如下所示：
總結
springboot是很方便開發，但還是有一些小缺陷的，想著以後會跟springboot多打交道，還是把使用springboot途中掉過的坑給羅列下來，希望大家能安全避開這些坑。
閱讀更多 Java高級開發 的文章
