invalid end header( bad central directory size)
异常描述
java.util.zip.ZipException: invalid END header (bad central directory size) at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(ZipFile.java:219) at java.util.zip.ZipFile. (ZipFile.java:149) at java.util.jar.JarFile. (JarFile.java:166) at java.util.jar.JarFile. (JarFile.java:103) at sun.net.www.protocol.jar.URLJarFile. (URLJarFile.java:93)
部署war包到tomcat之后，程序无法启动，说是解压错误
问题原因及第一种解决方法
war包文件格式其实就是zip，是需要解压的。而此异常就是解压过程中出现错误。
首先要保证war包完好，跟上传的时候比较一下大小。使用ftp上传有两种格式：文本格式和二进制格式，需要注意一定要选择二进制格式。 如果保证war包完好，可以直接使用unzip haha.war命令进行解压。 tomcat报这个错误说明tomcat无法解压这个文件，但是unzip命令还是可以解压的。解压之后并不报错，web程序正常运行。另一种解决方法
stackoverflow上说：查找是哪个jar包引起的异常，去本地maven仓库中找到该包对应的文件夹，删除之，重新下载之，重新打包就可以了。
UnsupportedClassVersionError
异常描述
java.lang.UnsupportedClassVersionError: org/apache/solr/client/solrj/SolrServerException : Unsupported major.minor version 51.0
主要原因是jdk的版本太低了，solr4.8以后需要编译在1.7的版本。
在Maven中设置的Java版本只能限制自己的源代码不能使用新版特性，并不能限制jar包。java8生成的jar包有可能无法再java6虚拟机上运行，因为虚拟机也在不停地变化。ThreadLocal不会自动清空
Servlet容器对于每个请求开辟一个线程处理
Servlet容器维护一个线程池 ThreadLocal不会自动清空它所维护的对象所以ThreadLocal中的对象有时需要手动清空。
启动tomcat 报错 Unsupported major.minor version 52.0
出现这个错误是因为编译的JDK版本，跟运行时所用的JDK版本不一致所导致的：低版本的jvm无法加载高版本的class文件造成的。
发现这个错误费了好大劲。Tomcat的日志文件重要的有三种：- catalina.out
- catalina.log
- localhost.log
出现问题之后三个日志对比着看比较好。
No such method error
java.lang.NoSuchMethodError: org.apache.lucene.codecs.blocktree.BlockTreeTermsWriter.validateSettings(II)V
出现此问题的原因多半是因为jar包重复。
以war包形式在tomcat上部署项目时，tomcat会自动解压war包。解压之后会把文件复制到与war包同名的文件夹中，如果该文件夹已经存在，则会合并。会导致意想不到的错误，所以在tomcat上部署项目时一定要先把旧的删掉，再部署新的。
Abstract Method Error
抽象方法错误，意思是调用了抽象方法。
这个错误的原因是：通过string加载某个类，这个类没有找到。 一个项目依赖两个jar包，如果这两个jar包都包含名为haha的包，当加载haha.MyClass时就难以判断去哪一个包下面去找，从而产生找不到类的错误。intellj idea maven 无效的目标发行版: 1.8
出现此问题，多半是版本问题。
可能的原因如下： 使用maven compile进行编译时报出此错误，这是因为本地JDK是1.7的，不可能编译成目标平台为1.8的代码。maven所调用的javac版本就是PATH环境变量里面的javac。 如果使用IntelliJ，那么可以使用界面maven小窗口编译成功，因为界面方式默认调用的jdk是跟项目相同的。另一种可能原因是插件版本太低，因为编译的时候需要设置一些参数，所以需要maven编译插件，该插件如果版本太低而编译目标太高，就会报此异常。
org.apache.maven.plugins maven-compiler-plugin 3.2 1.8 1.8 utf-8
Java 字符转换大坑
String s = "天下大势";System.out.println(new String(new String(s.getBytes("utf8"), "gbk").getBytes("gbk"), "utf8"));System.out.println(new String(new String(s.getBytes("utf8"), "ascii").getBytes("ascii"), "utf8")); 对于utf8编码的字符串s，如果用ascii进行解码，那么得到的错误无法恢复；
对于utf8编码的字符串s，如果用gbk进行解码，那么虽然得到乱码，但是还是能够转换回去的。 如果ascii码根本无法解码字符串s，那么得到的字符串s就是不准确的，即便是转换回去依旧不准确。 如果是gbk编码，虽然无法解码字符串s，但是它依旧可以转换回去。而ASCII则一错不复返了。