java开发中遇到各种异常记录以及解决方案（不定时更新）-博客-最代码

Chen.木难 2016-06-21 14:26:24

java开发中遇到各种异常记录以及解决方案（不定时更新）

1.java.lang.ClassNotFoundException: javax.servlet.jsp.jstl.core.Config

解决：缺少jar包：jstl.jar

2.javax.validation.ValidationException: Unable to find a default provider

解决：缺少jar包： hibernate-validator-4.2.0.Final.jar
validation-api-1.0.0.GA.jar
slf4j-api-1.6.1.jar、
都在hibernate-validator-4.2.0.Final-dist.zip这个文件中。

3.在运行java程序时出现 Error: could not open c:\program Files\Java\jre6\lib\amd64\jvm.cfg'

解决：

         卸载掉java后，如果还出现这种情况就到C:\windows\system32下的：
         java.exe
         javaw.exe
         javaws.exe
         三个文件就OK了。

4.javamail发送邮件异常 Must issue a STARTTLS command first

http://stackoverflow.com/questions/10509699/must-issue-a-starttls-command-first

ps:gmail smtp发送端口有465和587,

Gmail支持smtp转发和pop3接收.

POP3服务器地址： pop.gmail.com 端口：995 支持SSL

SMTP服务器地址： smtp.gmail.com 端口：465 或者 587 支持SSL（TSL）

465端口是SSL/TLS通讯协议的内容一开始就被保护起来了是看不到原文的。

587端口是STARTTLS协议的属于TLS通讯协议只是他是在STARTTLS命令执行后才对之后的原文进行保护的。

windows命令提示行下

>telnet smtp.gmail.com 587

220 mx.google.com ESMTP d1sm2045736tid.14
EHLO AO
250-mx.google.com at your service, [58.22.135.6]
250-SIZE 35651584
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 PIPELINING
AUTH LOGIN
530 5.7.0 Must issue a STARTTLS command first. d1sm2045736tid.14 （看到没第2次命令，输入AUTH他就提示“Must issue a STARTTLS command first.”）
STARTTLS
220 2.0.0 Ready to start TLS
.....这里开始邮件内容的通讯就被保护起来了
QUIT

ps:所以当使用465端口时，还需要配置

p.put("mail.smtp.socketFactory.class", "javax.net.ssl.SSLSocketFactory");

p.put("mail.smtp.socketFactory.fallback", "false");

5.NoClassDefFoundError: org/slf4j/LoggerFactory和NoClassDefFoundError: org/apache/log4j/LogManager解决方法

解决：http://www.cnblogs.com/xwdreamer/archive/2012/02/20/2359595.html

6.序列化相关异常

众所周知，当某class实现了Serializable接口后，由此class构建出的对象将具备序列化的能力，而Serializable这个接口中没有任何需要实现的方法，所以这个接口的作用仅仅是作为一个标记，告诉虚拟机，具有这个标记的对象，是可以被序列化的，而没有这个标记的则不要序列化。所以，虚拟机应该是可以将任何对象序列化的，只不过是它遵守了一个“道德“规范，仅序列化那些被允许可以序列化的。那为什么不是所有的对象都是可序列化的呢？我想也许是基于安全性的考量吧。

序列化的一般过程是：

在虚拟机A中，构造了class AClass的对象AObject
将AObject序列化写入到文件ObjectFile中
在虚拟机B中，读取文件ObjectFile
根据AClass和读取进来的byte[]，构造虚拟机B中的AClass的对象BObject

这里面，不好理解的事情是在第四步中，如果虚拟机B仅有AObject的数据，并不足以构造出BObject，它必须还需要有AClass的信息。也就是说，序列化，仅仅是把对象以二进制的形式写入到了文件之中，但是这些二进制该组织成什么样的一个东西，却并不能说明，所以还需要AClass的类型信息，这就如同交给了你一大堆的机器零件，还需要你拥有一本组装说明书，你才能把这些零件组装成一架波音747。:)。也就是说，序列化的仅仅是Object，而没有同时把这个Object所依赖的所有class一并序列化过去。那为什么不这么做呢？也许和ClassLoader有关？又和安全性有关？

在实现了Serializable接口的class中，需要声明一个long serialVersionUID，用来标明当前class的版本号：

如果在序列化写时的版本号和序列化读时的版本号，不一致，将会有异常：
java.io.InvalidClassException:
local class incompatible: stream classdesc serialVersionUID = …, local class serialVersionUID = …
那如果在class中不声明这个属性呢？那结果可以就会变得比较诡异了：
- 在序列化写的时候，虚拟机A会为它计算出一个serialVersionUID，计算的方法是依据class的信息，再具体我也不清楚了。
- 在序列化读的时候，虚拟机B也会为class计算出一个serialVersionUID，然后做比较。
- 那么如果两个虚拟机是不同类型的虚拟机，那么计算方法可能就不一样了，于是即使相同的class，serialVersionUID也可能会不同，不同的class的，理论上来说，也存在serialVersionUID相同的可能性，所以，serialVersionUID尽量由我们自己来指定，而不要由虚拟机来计算。
那如果serialVersionUID一致，而class发生了变化呢？
- 如果虚拟机A中的AClass有一个属性，而虚拟机B中的AClass，没有这个属性，那么这个属性将被忽略，而不会有异常。
- 如果虚拟机A中的AClass没有的属性，而在虚拟机B中多出来的属性，那么这个属性将被赋予一个缺省值，而不会有异常。
- 如果虚拟机A中的AClass有一个属性，在虚拟机B中的AClass也有这个属性，但这个属性的类型变了，比如说int变成了long，抑或其他的变化，将会有异常：
  java.io.InvalidClassException:
  incompatible types for field …

经过序列化而产生的异常都是 java.io.InvalidClassException，不会产生java.lang.ClassCastException，两者还是有比较大的区别的，从名字上就可以看得出来。

我自己遇到的问题是：local class incompatible: stream classdesc serialVersionUID = 4379444343007238900, local class serialVersionUID = -4347374884104808421
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:562)

解决办法是去除所有Eclipse自动生成的serialVersionUID，当去除所有的serialVersionUID 后还出现以上问题，重启tomcat就好了

打赏

0个评论