sun.misc.BASE64Decoder不推荐使用
大致原因
有URL的图片转为base64提交,我先将图片下载用流缓到内存然后进行base64编码,但是因测试环境服务过多机子配置也不高,内存就爆了
java.,javax.,org.,sun.
除了“sun”包,其它各个包都是Java平台的标准实现,并且今后也将被继续支持。一般说来,“sun”之类的包并不包含在Java平台的标准中,它与操作系统相关,在不同的操作系统(如Solaris,Windows,Linux,Mac等等)中的实现也各不相同,并且可能随着J2SE版本不定期变化。因此,直接调用“sun”包的程序代码并不是100%的Java实现。也就是说:“java.”包,“javax.”包,“org.”包是作为J2SE的API公开接口的一部分,如果程序直接调用这些包中的API,那么程序是可以运行在
所有Java平台上,而与操作系统无关;但“sun.”包并不是API公开接口的一部分,调用“sun”包的程序并不能确保工作在所有Java平台上,事实上,这样的程序并不能工作在今后的Java平台上。
所以在我的程序使用sun.misc.BASE64Decoder服务器压力上去了以后很可能出现因为方法效率很差导致内存溢出的问题,得亏是在测试环境发现的,否则上线了以后则会引起巨大的问题~
最后我则使用了java1.8的java.util.Base64类,或者也可以使用阿里的base64方法效率都很高。吃一堑长一智,以后尽量避免使用sun包下内容,每次加载包时一定需要看好了再加,而不是能用就可以。
java包分类
java.*
JavaSE的标准库,是java标准的一部分,是对外承诺的java开发接口,通常要保持向后兼容,一般不会轻易修改。包括其他厂家(IBMJDK/HPJDK/OpenJDK)在内,所有jdk的实现,在java.*上都是一样的。
javax.*
也是java标准的一部分,但是没有包含在标准库中,一般属于标准库的扩展。通常属于某个特定领域,不是一般性的api。
此上两者都属于java标准库,公有的API,遵循java平台规范,
com.sun.*
是sun的hotspot虚拟机中java.* 和javax.*的实现类。因为包含在rt中,所以我们也可以调用。但是因为不是sun对外公开承诺的接口,所以根据根据实现的需要随时增减,因此在不同版本的hotspot中可能是不同的,而且在其他的jdk实现中是没有的,调用这些类,可能不会向后兼容,所以一般不推荐使用。
org.*
是由企业或者组织提供的java类库,大部分不是sun公司提供的,同com.sun.*,不具备向后兼容性,会根据需要随时增减。其中比较常用的是w3c提供的对XML、网页、服务器的类和接口
sun.*包:
1、不是API公开接口的一部分,调用sun包的程序并不能确保工作在所有Java平台上,不同的操作系统中的实现可能不相同。
2、不同的jdk版本sun包中的类也可能不定期的变化,因此sun.*包中的类没有提供API文档及源码。
不建议使用
原始
修正base64编码
Loading...