org.hibernate.boot.InvalidMappingException: Could not parse mapping document: null (INPUT_STREAM)

项目场景：

项目中用到ftl模板，项目已经运行很长时间一直都没有发现过什么问题，直到有一天，公司买了一台电脑，想把这台电脑当做测试机来做。因为公司打印机需要连windows系统，所以这台电脑上也装上win10。

---

问题描述

突然有一天我们测试报告了一个错误提示
org.hibernate.boot.InvalidMappingException: Could not parse mapping document: null (INPUT_STREAM)

---

原因分析：

收到这个反馈，首先想到要先去正式环境试下，看有没有同样的问题。结果还好，正式环境没问题。要确定是程序的问题（因为公司有加密程序，受加密程序影响的问题，也偶有发生）还是数据库的问题，为了排查问题，把测试环境的jar包拿到本地来试，用本地数据库，问题重现。但是本地ide跑程序不能重现这个问题，排除数据库问题。
锁定是jar包有问题，然后想到是不是受操作系统环境影响。于是把正式环境的jar包拿到本地来试（正式环境是linux环境），问题重现，同样的jar包正式环境没问题。基本上可以确定，是受操作系统环境影响。
这个时候，想windows和linux操作系统最大的差别在哪（从程序运行的角度来看），在默认编码！怀疑是编码影响。
于是根据报错信息，找到程序有个地方是调用string的getBytes方法，没有指定编码。
经过查找资料，java的string.getBytes方法没有明确指定编码，会按规则来指定。
1：以main函数形式运行
main函数直接以debug或者run形式运行，jvm编码格式则为当前文件格式；
2：tomcat环境下运行
tomcat服务器依赖于本机系统，不设置编码格式的时候，tomcat服务器的运行编码依赖于本机，windows下编码为GBK,
分析程序代码，发现读ftl到内存的时候指定了utf-8编码，但是getbytes的时候未指定，于是程序按照默认的规则来编码。
因为之前测试环境和正式环境都是linux默认编码都是utf-8，而本地开发环境ide都指定为utf-8编码，所以此问题一直未能发现。

---

解决方案：

原因知道了，解决起来就简单了，string.getBytes(“UTF-8”)，指定编码即可。

反思

java技术栈一直的优势就在于跨平台，一直以来平台间的差异很少被提及。本次问题的出现，表明，此前的知识还是有漏洞，导致在问题发生时，并不能第一时间想到是编码导致的问题。活到老学到老，尽量补齐知识上的漏洞，才能减少这类意外情况的发生。