spring下载sftp字节为0（idea设置springboot启动jvm参数）

本文目录

• idea设置springboot启动jvm参数
• 如何解决Unsupported major.minor version 52.0问题
• java连接Sftp服务器后，使用第三方jar com.jcraft.jsch.ChannelSftp;用get()方法获取的InputStream流为空
• springbootassistant修改字节码
• 为什么FTP上传的文件是0字节，FTP上传文件0字节的解决办法
• spring 怎么初始化加密的类
• Springboot使用ftp进行文件上传下载

idea设置springboot启动jvm参数

idea设置springboot启动jvm参数，设置方式，通过ldea设置，配置文件。参数说明参数说明-Xms初始化堆内存大小，eg.-Xms1G-Xmx堆内存最大值，eg.-Xms1G，通常与-Xms设置相同的值-XX：ReservedCodeCacheSize代码缓存，它是用来存储已编译方法生成的本地代码。代码缓存确实很少引起性能问题，但是一旦发生其影响可能是毁灭性的。如果代码缓存被占满，JVM会打印出一条警告消息，并切换到interpreted-only模式：JIT编译器被停用，字节码将不再会被编译成机器码。因此，应用程序将继续运行，但运行速度会降低一个数量级，直到有人注意到这个问题。就像其他内存区域一样，我们可以自定义代码缓存的大小。它们的参数都eg.-XX：ReservedCodeCacheSize=240m-XX：InitialC查看更多。

如何解决Unsupported major.minor version 52.0问题

一：要解决的问题我们在尝鲜 JDK1.5 的时候，相信不少人遇到过 Unsupported major.minor version 49.0 错误，当时定会茫然不知所措。因为刚开始那会儿，网上与此相关的中文资料还不多，现在好了，网上一找就知道是如何解决，大多会告诉你要使用 JDK 1.4 重新编译。那么至于为什么，那个 major.minor 究竟为何物呢？这就是本篇来讲的内容，以使未错而先知。我觉得我是比较幸运的，因为在遇到那个错误之前已研读过《深入 Java 虚拟机》第二版，英文原书名为《Inside the Java Virtual Machine》( Second Edition)，看时已知晓 major.minor 藏匿于何处，但没有切身体会，待到与 Unsupported major.minor version 49.0 真正会面试，正好是给我验证了一个事实。首先我们要对 Unsupported major.minor version 49.0 建立的直接感觉是：JDK1.5 编译出来的类不能在 JVM 1.4 下运行，必须编译成 JVM 1.4 下能运行的类。(当然，也许你用的还是 JVM 1.3 或 JVM 1.2，那么就要编译成目标 JVM 能认可的类)。这也解决问题的方向。二：major.minor 栖身于何处何谓 major.minor，且又居身于何处呢？先感性认识并找到 major.minor 来。写一个 Java Hello World! 代码，然后用 JDK 1.5 的编译器编译成，HelloWorld.javapackage com.unmi;public class HelloWorld {public static void main(String args){System.out.println("Hello, World!");} } package com.unmi;public class HelloWorld{ public static void main(String args) { System.out.println("Hello, World!"); }}用 JDK 1.5 的 javac -d . HelloWorld.java 编译出来的字节码 HelloWorld.class 用 UltraEdit 打开来的内容如图所示：从上图中我们看出来了什么是 major.minor version 了，它相当于一个软件的主次版本号，只是在这里是标识的一个 Java Class 的主版本号和次版本号，同时我们看到 minor_version 为 0x0000，major_version 为 0x0031，转换为十制数分别为0 和 49，即 major.minor 就是 49.0 了。三：何谓 major.minor 以及何用Class 文件的第 5-8 字节为 minor_version 和 major_version。Java class 文件格式可能会加入新特性。class 文件格式一旦发生变化，版本号也会随之变化。对于 JVM 来说，版本号确定了特定的 class 文件格式，通常只有给定主版本号和一系列次版本号后，JVM 才能够读取 class 文件。如果 class 文件的版本号超出了 JVM 所能处理的有效范围，JVM 将不会处理该 class 文件。在 Sun 的 JDK 1.0.2 发布版中，JVM 实现支持从 45.0 到 45.3 的 class 文件格式。在所有 JDK 1.1 发布版中的 JVM 都能够支持版本从 45.0 到 45.65535 的 class 文件格式。在 Sun 的 1.2 版本的 SDK 中，JVM 能够支持从版本 45.0 到46.0 的 class 文件格式。1.0 或 1.2 版本的编译器能够产生版本号为 45.3 的 class 文件。在 Sun 的 1.2 版本 SDK 中，Javac 编译器默认产生版本号为 45.3 的 class 文件。但如果在 javac 命令行中指定了 -target 1.2 标志，1.2 版本的编译器将产生版本号为 46.0 的 class 文件。1.0 或 1.1 版本的 JVM 上不能运行使用-target 1.2 标志所产生的 class 文件。JVM 实现的 第二版中修改了对 class 文件主版本号和次版本号的解释。对于第二版而言，class 文件的主版本号与 Java 平台主发布版的版本号保持一致(例如：在 Java 2 平台发布版上，主版本号从 45 升至 46)，次版本号与特定主平台发布版的各个发布版相关。因此，尽管不同的 class 文件格式可以由不同的版本号表示，但版本号不一样并不代表 class 文件格式不同。版本号不同的原因可能只是因为 class 文件由不同发布版本的 java 平台产生，可能 class 文件的格式并没有改变。上面三段节选自《深入 Java 虚拟机》，啰嗦一堆，JDK 1.2 开启了 Java 2 的时代，但那个年代仍然离我们很远，我们当中很多少直接跳在 JDK 1.4 上的，我也差不多，只是项目要求不得不在一段时间里委屈在 JDK 1.3 上。不过大致我们可以得到的信息就是每个版本的 JDK 编译器编译出的 class 文件中都带有一个版本号，不同的 JVM 能接受一个范围 class 版本号，超出范围则要出错。不过一般都是能向后兼容的，知道 Sun 在做 Solaris 的一句口号吗？保持对先前版本的 100% 二进制兼容性，这也是对客户的投资保护。四：其他确定 class 的 major.minor version 办法1）Eclipse 中查看Eclipse 3.3 加入的新特征，当某个类没有关联到源代码，打开它会显示比较详细的类信息，当然还未到源码级别了，看下图是打开 2.0 spring.jar 中 ClasspathXmlApplicationContext.class 显示的信息2）命令 javap -verbose对于编译出的 class 文件用 javap -verbose 能显示出类的 major.minor 版本，见下图：3) MANIFEST 文件把 class 打成的 JAR 包中都会有文件 META-INF\MANIFEST，这个文件一般会有编译器的信息，下面列几个包的 META-INF\MANIFEST 文件内容大家看看·Velocity-1.5.jar 的 META-INFO\MANIFEST 部份内容Manifest-Version: 1.0Ant-Version: Apache Ant 1.7.0Created-By: Apache AntPackage: org.apache.velocityBuild-Jdk: 1.4.2_08Extension-Name: velocity我们看到是用 ant 打包，构建用的JDK是 1.4.2_08，用 1.4 编译的类在 1.4 JVM 中当然能运行。如果那人用 1.5 的 JDK 来编译，然后用 JDK 1.4+ANT 来打包就太无聊了。·2.0 spring.jar 的 META-INFO\MANIFEST 部份内容Manifest-Version: 1.0Ant-Version: Apache Ant 1.6.5Created-By: 1.5.0_08-b03 (Sun Microsystems Inc.)Implementation-Title: Spring Framework这下要注意啦，它是用的 JDK 1.5 来编译的，那么它是否带了 -target 1.4 或 -target 1.3 来编译的呢？确实是的，可以查看类的二进制文件，这是最保险的。所在 spring-2.0.jar 也可以在 1.4 JVM 中加载执行。·自已一个项目中用 ant 打的 jar 包的 META-INFO\MANIFESTManifest-Version: 1.0Ant-Version: Apache Ant 1.7.0Created-By: 1.4.2-b28 (Sun Microsystems Inc.)用的是 JDK 1.4 构建打包的。第一第二种办法能明确知道 major.minor version，而第三种方法应该也没问题，但是碰到变态构建就难说了，比如谁把那个 META-INFO\MANIFEST 打包后换了也未可知。直接查看类的二进制文件的方法可以万分保证，准确无误，就是工具篡改我也认了。五：编译器比较及症节之所在现在不妨从 JDK 1.1 到 JDK 1.7 编译器编译出的 class 的默认 minor.major version 吧。（又走到 Sun 的网站上翻腾出我从来都没用过的古董来）JDK 编译器版本target 参数十六进制 minor.major十进制 minor.majorjdk1.1.8不能带 target 参数00 03 00 2D45.3jdk1.2.2不带(默认为 -target 1.1)00 03 00 2D45.3jdk1.2.2-target 1.200 00 00 2E46.0jdk1.3.1_19不带(默认为 -target 1.1)00 03 00 2D45.3jdk1.3.1_19-target 1.300 00 00 2F47.0j2sdk1.4.2_10不带(默认为 -target 1.2)00 00 00 2E46.0j2sdk1.4.2_10-target 1.400 00 00 3048.0jdk1.5.0_11不带(默认为 -target 1.5)00 00 00 3149.0jdk1.5.0_11-target 1.4 -source 1.400 00 00 3048.0jdk1.6.0_01不带(默认为 -target 1.6)00 00 00 3250.0jdk1.6.0_01-target 1.500 00 00 3149.0jdk1.6.0_01-target 1.4 -source 1.400 00 00 3048.0jdk1.7.0不带(默认为 -target 1.6)00 00 00 3250.0jdk1.7.0-target 1.700 00 00 3351.0jdk1.7.0-target 1.4 -source 1.400 00 00 3048.0Apache Harmony 5.0M3不带(默认为 -target 1.2)00 00 00 2E46.0Apache Harmony 5.0M3-target 1.400 00 00 3048.0上面比较是 Windows 平台下的 JDK 编译器的情况，我们可以此作些总结：1) -target 1.1 时 有次版本号，target 为 1.2 及以后都只用主版本号了，次版本号为 02) 从 1.1 到 1.4 语言差异比较小，所以 1.2 到 1.4 默认的 target 都不是自身相对应版本3) 1.5 语法变动很大，所以直接默认 target 就是 1.5。也因为如此用 1.5 的 JDK 要生成目标为 1.4 的代码，光有 -target 1.4 不够，必须同时带上 -source 1.4，指定源码的兼容性，1.6/1.7 JDk 生成目标为 1.4 的代码也如此。4) 1.6 编译器显得较为激进，默认参数就为 -target 1.6。因为 1.6 和 1.5 的语法无差异，所以用 -target 1.5 时无需跟着 -source 1.5。5) 注意 1.7 编译的默认 target 为 1.66) 其他第三方的 JDK 生成的 Class 文件格式版本号同对应 Sun 版本 JDK7) 最后一点最重要的，某个版本的 JVM 能接受 class 文件的最大主版本号不能超过对应 JDK 带相应 target 参数编译出来的 class 文件的版本号。上面那句话有点长，一口气读过去不是很好理解，举个例子：1.4 的 JVM 能接受最大的 class 文件的主版本号不能超过用 1.4 JDK 带参数 -target 1.4 时编译出的 class 文件的主版本号，也就是 48。因为 1.5 JDK 编译时默认 target 为 1.5，出来的字节码 major.minor version 是 49.0，所以 1.4 的 JVM 是无法接受的，只有抛出错误。那么又为什么从 1.1 到 1.2、从 1.2 到 1.3 或者从 1.3 到 1.4 的 JDK 升级不会发生 Unsupported major.minor version 的错误呢，那是因为 1.2/1.3/1.4 都保持了很好的二进制兼容性，看看 1.2/1.3/1.4 的默认 target 分别为 1.1/1.1/1.2 就知道了，也就是默认情况下1.4 JDK 编译出的 class 文件在 JVM 1.2 下都能加载执行，何况于 JVM 1.3 呢？（当然要去除使用了新版本扩充的 API 的因素）六：找到问题解决的方法那么现在如果碰到这种问题该知道如何解决了吧，还会像我所见到有些兄弟那样，去找个 1.4 的 JDK 下载安装，然后用其重新编译所有的代码吗？其实大可不必如此费神，我们一定还记得 javac 还有个 -target 参数，对啦，可以继续使用 1.5 JDK，编译时带上参数 -target 1.4 -source 1.4 就 OK 啦，不过你一定要对哪些 API 是 1.5 JDK 加入进来的了如指掌，不能你的 class 文件拿到 JVM 1.4 下就会 method not found。目标 JVM 是 1.3 的话，编译选项就用 -target 1.3 -source 1.3 了。相应的如果使用 ant ，它的 javac 任务也可对应的选择 target 和 source《javac target="1.4" source="1.4" ............................/》如果是在开发中，可以肯定的是现在真正算得上是 JAVA IDE 对于工程也都有编译选项设置目标代码的。例如 Eclipse 的项目属性中的 Java Compiler 设置，如图自已设定编译选项，你会看到选择不同的 compiler compliance level 是，Generated class files compatibility 和 Source compatibility 也在变，你也可以手动调整那两项，手动设置后你就不用很在乎用的什么版本的编译器了，只要求他生成我们希望的字节码就行了，再引申一下就是即使源代码是用 VB 写的，只要能编译成 JVM 能执行的字节码都不打紧。在其他的 IDE 也能找到相应的设置对话框的。其他时候，你一定要知道当前的 JVM 是什么版本，能接受的字节码主版本号是多少（可对照前面那个表）。获息当前 JVM 版本有两种途径：第一：如果你是直接用 java 命令在控制台执行程序，可以用 java -version 查看当前的 JVM 版本，然后确定能接受的 class 文件版本第二：如果是在容器中执行，而不能明确知道会使用哪个 JVM，那么可以在容器中执行的程序中加入代码　System.getProperty("java.runtime.version"); 或 System.getProperty("java.class.version")，获得 JVM 版本和能接受的 class 的版本号。最后一绝招，如果你不想针对低版本的 JVM 用 target 参数重新编译所有代码；如果你仍然想继续在代码中用新的 API 的话；更有甚者，你还用了 JDK 1.5 的新特性，譬如泛型、自动拆装箱、枚举等的话，那你用 -target 1.4 -source 1.4 就没法编译通过，不得不重新整理代码。那么告诉你最后一招，不需要再从源代码着手，直接转换你所正常编译出的字节码，继续享用那些新的特性，新的 API，那就是：请参考之前的一篇日志：Retrotranslator让你用JDK1.5的特性写出的代码能在JVM1.4中运行 ，我就是这么用的，做好测试就不会有问题的。七：再议一个实际发生的相关问题这是一个因为拷贝 Tomcat 而产生的 Unsupported major.minor version 49.0 错误。情景是：我本地安装的是 JDK 1.5，然后在网上找了一个 EXE 的 Tomcat 安装文件安装了并且可用。后来同事要一个 Tomcat，不想下载或安装，于是根据我以往的经验是把我的 Tomcat 整个目录拷给他应该就行了，结果是拿到他那里浏览 jsp 文件都出现 Unsupported major.minor version 49.0 错误，可以确定的是他安装的是 1.4 的 JDK，但我还是有些纳闷，先前对这个问题还颇有信心的我傻眼了。惯性思维是编译好的 class 文件拿到低版本的 JVM 会出现如是异常，可现并没有用已 JDK 1.5 编译好的类要执行啊。后来仔细看异常信息，终于发现了 %TOMCAT_HOME%\common\lib\tools.jar 这一眉目，因为 jsp 文件需要依赖它来编译，打来这个 tools.jar 中的一个 class 文件来看看，49.0，很快我就明白原来这个文件是在我的机器上安装 Tomcat 时由 Tomcat 安装程序从 %JDK1.5%\lib 目录拷到 Tomcat 的 lib 目录去的，造成在同事机器上编译 JSP 时是 1.4 的 JVM 配搭着 49.0 的 tools.jar，那能不出错，于是找来 1.4 JDK 的 tools.jar 替换了 Tomcat 的就 OK 啦。八：小结其实理解 major.minor 就像是我们可以这么想像，同样是微软件的程序，32 位的应用程序不能拿到 16 位系统中执行那样。如果我们发布前了解到目标 JVM 版本，知道怎么从 java class 文件中看出 major.minor 版本来，就不用等到服务器报出异常才着手去解决，也就能预知到可能发生的问题。其他时候遇到这个问题应具体解决，总之问题的根由是低版本的 JVM 无法加载高版本的 class 文件造成的，找到高版本的 class 文件处理一下就行了

java连接Sftp服务器后，使用第三方jar com.jcraft.jsch.ChannelSftp;用get()方法获取的InputStream流为空

java连接Sftp服务器后，使用第三方jar com.jcraft.jsch.ChannelSftp;用get()方法获取的InputStream流为空，检查下第3方初始化这些写对没有，或者就是没得到流，打印看看，解决问题。

springbootassistant修改字节码

1、在application，properties中设置。2、自己手写编码过滤器。3、使用java配置写一个字符编码配置类就行了。

为什么FTP上传的文件是0字节，FTP上传文件0字节的解决办法

使用同一个电脑，同样的软件对另一个网站的ftp操作确一切正常。这个不能正常ftp传输的网站无论上传或下载后的文件大小变成0字节。在ftp环境下可以删除远程的文件。另外，进入默认的文件夹后根本无法进入上级和下级目录，既无法打开。有时候登录时还不能正常进入默认远程文件夹。使用leapftp登录后的右上部的往根目录的箭头也不见了。后来使用flashfxp、dreamwere、ie去登录ftp地址，其结果都相同。与虚拟主机服务商反复联系。虚拟主机的空间尚存在比较大的余量。文件空间未超过设定值。服务商确认那边没问题。虚拟主机服务商又说我的电脑有问题。我又把我的电脑一键恢复了。还是没有解决。偶然的机会去外地公差，在外地他人的电脑里把我的网站ftp修改成功了。可见两头没问题，而在异地使用ftp可以正常将文件上传和修改了。故障信息代码见下图：错误代码一错误代码二错误代码三问题的主要表现是登录后马上打开www文件夹。可以看到此文件夹里的文件，可以进行删除。但是，不能对其进行其他任何操作。如果上传文件大小为0。打开上级文件夹或下级文件夹都看不到该文件夹里的文件或文件夹。最后，虚拟主机服务商建议修改我的电脑的首选dns服务器地址和备用dns服务器地址。还是没有解决。最后，找到了宽带介入服务商，在她那里对接入设置进行了调整。问题得到了解决。谁能想到宽带接入商还会影响到ftp的传输。看来，虚拟主机系统的不同（windows、unix等）和宽带接入的设置都会影响到ftp的正常传输。

spring 怎么初始化加密的类

hi， 下面是一个classloader的例子， 你需要做的就是更新那个getClassData函数，先做解密，然后将结果的byte返回就好了。有问题的话，请告诉我。package classloader; import java.io.ByteArrayOutputStream; import java.io.InputStream; import java.net.URL; /** * 加载网络class的ClassLoader */ public class NetworkClassLoader extends ClassLoader { private String rootUrl; public NetworkClassLoader(String rootUrl) { this.rootUrl = rootUrl; } @Override protected Class《?》 findClass(String name) throws ClassNotFoundException { Class clazz = null;//this.findLoadedClass(name); // 父类已加载 //if (clazz == null) { //检查该类是否已被加载过 byte classData = getClassData(name); //根据类的二进制名称,获得该class文件的字节码数组 if (classData == null) { throw new ClassNotFoundException(); } clazz = defineClass(name, classData, 0, classData.length); //将class的字节码数组转换成Class类的实例 //} return clazz; } private byte getClassData(String name) { InputStream is = null; try { String path = classNameToPath(name); URL url = new URL(path); byte; int len = -1; is = url.openStream(); ByteArrayOutputStream baos = new ByteArrayOutputStream(); while((len = is.read(buff)) != -1) { baos.write(buff,0,len); } return baos.toByteArray(); } catch (Exception e) { e.printStackTrace(); } finally { if (is != null) { try { is.close(); } catch(IOException e) { e.printStackTrace(); } } } return null; } private String classNameToPath(String name) { return rootUrl + "/" + name.replace(".", "/") + ".class"; } }

Springboot使用ftp进行文件上传下载

首先要在阿里云ECS上搭建ftp服务器，默认是有vsftpd ，它是 Linux 下的一款小巧轻快、安全易用的 FTP 服务器软件。 用下面命令查看是否安装了vsftpd，阿里云ECS默认是安装好的，如果没有参考网上文章安装。 新建用户ftpuser： useradd ftpuser -d /home/ftpfile 设置用户密码： passwd ftpuser 多数教程里面使用的标准的ftp maven依赖： 但是我使用的是阿里云的ECS上安装的ftp，在进行连接的时候他提示协议不正确，需要使用sftp，所以maven依赖换成了：