原文地址：https://bbs.huaweicloud.com/blogs/175240前言JDK是一个强大的开发工具集，里面提供了大量的通用类和API，在Java代码开发过程中也被大量使用，但事实上，你对JDK真有你想象当中的那么“熟悉”吗？在代码检视过程中，经常发现的一些JDK中的类或API未被合理地、正确地使用，本篇将列举几种最常用的案例，并进行分析说明。案例分析1.       被误用的SimpleDateFormatSimpleDateFormat在平常的开发过程中比较常用，我简单的搜索了一下，发现我们团队现在的产品中有将近200处使了该类，但是在平常的代码检视过程中，发现被误用的情况还是比较多的。SimpleDateFormat是线程不安全对象，但很多人并不知道，而是想当然将它当成线程安全的工具类使用，直接应用于多线程并发场景，比如下面这段代码。  错误的用法 public class AlarmUtil {   ...   private static SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");   ...   public static void updateAlarm(){     ...         aMsg.setAlarmGenTime(df.parse(df.format(new Date())));     ...   }   ... }当上面代码片段中的updateAlarm方法被高频率并发调用的时候，极有可能出现结果不符合预期，或者抛异常的情况。正确的用法应当是避免SimpleDateFormat对象被并发访问。  正确的用法public class AlarmUtil {   ...   public static void updateAlarm(){     ...     SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");       aMsg.setAlarmGenTime(df.parse(df.format(new Date())));     ...   }   ... }2.       被错用的System.currentTimeMillis()System.currentTimeMillis()的作用是获取当前系统时间戳，精度为毫秒，这点相信大家并不陌生。在代码检视过程，发现该方法常在计时场景中，用于开始时间和结束时间的获取。事实上这种用法是有问题的，原因是此方法取的是系统当前时间，请注意，这个时间在Java程序运行过程中，是可以人为修改的，因此在计时的场景中使用该方法是不可靠的。比如在下面这段代码中，在获取了起始时间之后，到获取结束时间之前的这段时间里，如果有人将系统时间往过去调了，则计算出来的时间差可能比实际时间差要短，甚至可能是个负数，反之，如果往未来调了，则计算出来的时间差可能比实际时间差要长。  错误的用法long start = System.currentTimeMillis(); ... long end = System.currentTimeMillis(); ... logger.info("       ===== The thread consumes time is : " + (end - start) + " ms");在计时场景中，获取开始时间和结束时间正确的做法，应当是使用System.nanoTime()。System.nanoTime()专用于测量已过的时间，与系统或钟表时间等其他任何时间概念无关，程序运行过程中，外界是无法干预的。  正确的用法long start = System.nanoTime(); ... long end = System.nanoTime(); ... long usedTime = TimeUnit.MILLISECONDS.convert((end - start), TimeUnit.NANOSECONDS); logger.info("       ===== The thread consumes time is : " + usedTime + " ms");3.       被滥用的StringBuilder在编程军规中有一条“在进行三个字符串（不包含三个）以上的串联操作时必须使用StringBuilder或StringBuffer，禁止使用‘+’”，原因是StringBuilder或StringBuffer要比“+”操作符的性能高。于是大家便认为，在进行字符串连接的时候，使用StringBuilder一定是没错的，便开始在自己的代码中大量使用。然而，是不是所有字符串连接的场景都有必要使用StringBuilder呢？答案当然是否定的。比如在下面这段代码，其实使用StringBuilder和直接使用“+”操作符，在性能上并无差异。研究过Java编译及.class文件结构的人一定知道，Java代码中的“+”表达式最终都会被编译成new StringBuilder(xxx)….append(xx).toString()的形式。因此在连接固定个数的字符串时，使用StringBuilder并不能带来明显的性能提升，反而会降低代码的可读性。  滥用的情况public static String errorMsg(String content) {   return new StringBuilder(">>>>>>Error is: ").append(content).append(">>>>>>").toString(); }但是，话又说回来，当需要连接的字符串个数不固定的时候，比如要将一个列表中的所有字符串进行连接，此时是一定要使用StringBuilder的，连接字符串个数越多，带来的性能提升就越明显。4.       被遗忘的ThreadLocal在案例1中，我们是要求将SimpleDateFormat挪到方法内部去实例化，这样就避免了并发访问的问题。有些同事也许就会问了，这样每次调用方法的时候，都要new一个SimpleDateFormat对象，会不会有性能问题？这个问题很好，这样做确实会带来一定的性能损失，可是不这样做，我们又会存在并发问题。愁死人了，难道就没有两全其美的方法？即解决并发的问题，又不至于让性能损失太多。这个时候我们就需要用于ThreadLocal类了。ThreadLocal就好比是一个Map，它以线程对象作为Key，每个线程调用它的get方法，获取的都是专属于这个线程的Value。在内存富余的情况下，这个专属对象会一直放在ThreadLocal对象中，下次再get的时候，获取的还是同一个对象，这样便解决了频繁创建的问题。细心的同事会发现，我前面特别提到是在“内存富余”的情况下，如果内存不富余呢？ThreadLocal中是通过软引用持有Value对象的，当内存比较紧张的时候，ThreadLocal中的未被使用的Value有可能会垃圾回收掉。因此，通常我们在使用ThreadLocal的时候，会复写它的initialValue方法，保证Value被回收掉之后，下次再调get方法，可以获得一个新的Value，而不是null。按照这个方法，将案例1中的代码优化一下。  优化的代码public class AlarmUtil {   ...   static final ThreadLocal<SimpleDateFormat> FORMAT_CACHE = new ThreadLocal<SimpleDateFormat>() {     @Override     protected SimpleDateFormat initialValue() {       return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");     }   };   ...   public static void updateAlarm(){     ...     SimpleDateFormat df = FORMAT_CACHE.get();     // 如果需要，别忘了在使用之前，重置对象     aMsg.setAlarmGenTime(df.parse(df.format(new Date())));     ...   }   ... }大家要注意的是，由于ThreadLocal中的对象主要用来被复用的，因此在get出来之后，首先做的就是重置该对象，重置的方法可能是重新初始化，也可能是清空，也有可能是其它。当然，ThreadLocal也不是万能的，从它的实现原理，我们可以知道，当我们的应用如果不是基于线程池的，使用ThreadLocal其实并不能给我们带来性能上的提升。PS：在平常的交流中，发现有部分同事也有用到ThreadLocal对象，但是当做线程上下文来用，用于在前后代码逻辑传递一些对象，这实际上是不可取的，原因就在于，我们前面提到的，ThreadLocal是通过软引用持有对象的，在程序运行的过程，ThreadLocal中持有的对象极有可能被垃圾回收机制回收掉，从而导致后续代码因为获取不到这些对象而出错。结语  本篇只列举了4种最常见的对JDK的类和API使用不当的场景，其实类似的问题还有很多。上面的例子能给我们带来什么启示？我们在使用任何API前，一定仔细阅读其API说明，有必要时，还要了解清楚其内部实现原理，这样才能做到不错用、不误用、不滥用、不漏用。

#化鲲为鹏，我有话说# > 题外话：很高兴能够申请成功鲲鹏的公测，收到消息，第一时间申请了鲲鹏服务器，打算好好利用这段时间对鲲鹏服务器在企业应用可用性上进行测试，毕竟ARM和X86还是有很大差别的，很多企业级应用能否在鲲鹏上稳定运行，是否能够保证性能，是否可以适应技术架构及其中间件环境，是选择鲲鹏的一个重要的考量。本次我就先对java及其相关环境进行测试。这是我的第一帖，后续我还会持续对鲲鹏的测试反馈发帖交流。 首先，对于鲲鹏[官网介绍](https://www.huaweicloud.com/kunpeng/software/openjdk.html)其是支持OpenJDK环境的，但是在企业中，很少直接使用OpenJDK，而是使用oracle官方版本更多一些。那我就先在鲲鹏服务中先搭建jdk环境，本次测试使用的jdk8，分别安装OpenJDK和Oracle官方jdk环境。 ## 0. 试验环境 服务器规格： 鲲鹏通用计算增强型 | kc1.15xlarge.2 操作系统 ： Ubuntu 18.04 64bit with ARM ## 1.OpenJDK 服务器初始系统中已经安装了OpenJDK，安装版本如下： ```bash openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-8u212-b03-0ubuntu1.18.04.1-b03) OpenJDK 64-Bit Server VM (build 25.212-b03, mixed mode) ``` 如果你使用其他系统，可以参考[鲲鹏官方的安装说明](https://www.huaweicloud.com/kunpeng/software/openjdk.html) ## 2. Oracle官方版本 - 首先需要卸载鲲鹏上自带的openjdk ```bash apt-get autoremove openjdk-8-jdk ``` - 然后下载oracle官方jdk，这里时[下载地址](https://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8u211-later-5573849.html)，这里需要注意，一定要下载RAM版本的jdk，否则无法运行。 - 加压并安装jdk ```bash tar -vzxf jdk-8u212-linux-arm64-vfp-hflt.tar.gz mv jdk1.8.0_212/ jdk vi /etc/profile # 在文件最后加上下面内容 export JAVA_HOME=/opt/jdk export PATH=$PATH:$JAVA_HOME/bin ``` - 验证是否安装成功 ```bash java -version # 看到以下内容说明已经安装完成 java version "1.8.0_212" Java(TM) SE Runtime Environment (build 1.8.0_212-b10) Java HotSpot(TM) 64-Bit Server VM (build 25.212-b10, mixed mode) ``` ## 3.总结 可以看到，基于鲲鹏的JAVA环境安装过程和基于X86的安装过程并没有什么区别，而且无论从开源社区还是oracke官方都是支持ARM框架的JAVA环境。而JAVA是基于跨平台的，只要能够正常运行JAVA环境，那么基于JAVA的企业级应用，都可以很容易的迁移到麒麟服务器上。

CLoudLink支持企业使用自认证接口集成，实现了自认证的企业，用户可以直接使用企业内部账号/密码登陆CLoudLink。但是AES GCM算法需要JDK 1.8及以上版本的支持，低于1.8的版本会出现如下报错：这时需要在项目中增加开源软件包bcprov-jdk15on的依赖：Maven pom.xml样例：在启动加解密的代码中加入如下代码Security.addProvider(new BouncyCastleProvider()); //support jdk 1.7如下图所示：这样应该就可以解决jdk版本问题了。O(∩_∩)O~

有时候老版本软件的移植依赖 这个 jrub-complete-1.6.8 源码在：https://github.com/jruby/jruby/releases/tag/1.6.8尝试编译，貌似JDK8移除了apt，编译报错：[INFO] BUILD FAILED[INFO] /build/01_maven_project/jruby/jruby-1.6.8/build.xml:680: The following error occurred while executing this line:[INFO] /build/01_maven_project/jruby/jruby-1.6.8/build.xml:264: Problem: failed to create task or type apt[INFO] Cause: The name is undefined.[INFO] Action: Check the spelling.[INFO] Action: Check that any custom tasks/types have been declared.[INFO] Action: Check that any <presetdef>/<macrodef> declarations have taken place.用JDK1.7，也报错：[INFO] BUILD FAILED[INFO] /build/01_maven_project/jruby/jruby-1.6.8/build.xml:681: The following error occurred while executing this line:[INFO] /build/01_maven_project/jruby/jruby-1.6.8/build.xml:282: The following error occurred while executing this line:[INFO] /build/01_maven_project/jruby/jruby-1.6.8/build.xml:287: Java returned: 1[INFO][INFO] Total time: 17 seconds[INFO] ------------------------------------------------------------------------[INFO] BUILD FAILURE-X：[INFO] BUILD FAILED[INFO] /build/01_maven_project/jruby/jruby-1.6.8/build.xml:681: The following error occurred while executing this line:[INFO] /build/01_maven_project/jruby/jruby-1.6.8/build.xml:282: The following error occurred while executing this line:[INFO] /build/01_maven_project/jruby/jruby-1.6.8/build.xml:287: Java returned: 1[INFO][INFO] Total time: 16 seconds[INFO] ------------------------------------------------------------------------[INFO] Reactor Summary:[INFO][INFO] JRuby Shared 1.6.8 ................................. SUCCESS [  3.443 s][INFO] JRuby Common ....................................... SUCCESS [  0.061 s][INFO] JRuby .............................................. FAILURE [ 18.315 s][INFO] JRuby Core ......................................... SKIPPED[INFO] JRuby Complete ..................................... SKIPPED[INFO] JRuby Stdlib ....................................... SKIPPED[INFO] JRuby Distribution ................................. SKIPPED[INFO] JRuby Rake Plugin .................................. SKIPPED[INFO] docs ............................................... SKIPPED[INFO] JRuby Manual pages 1.6.8 ........................... SKIPPED[INFO] ------------------------------------------------------------------------[INFO] BUILD FAILURE[INFO] ------------------------------------------------------------------------[INFO] Total time: 22.313 s[INFO] Finished at: 2019-07-30T11:07:45+08:00[INFO] ------------------------------------------------------------------------[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.1:exec (default) on project jruby: Result of /bin/sh -c cd /build/01_maven_project/jruby/jruby-1.6.8/maven/jruby/../.. && ant jar-dist execution is: '1'. -> [Help 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.1:exec (default) on project jruby: Result of /bin/sh -c cd /build/01_maven_project/jruby/jruby-1.6.8/maven/jruby/../.. && ant jar-dist execution is: '1'.    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:57)    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)    at java.lang.reflect.Method.invoke (Method.java:606)    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)Caused by: org.apache.maven.plugin.MojoExecutionException: Result of /bin/sh -c cd /build/01_maven_project/jruby/jruby-1.6.8/maven/jruby/../.. && ant jar-dist execution is: '1'.    at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:260)    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:57)    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)    at java.lang.reflect.Method.invoke (Method.java:606)    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)[ERROR][ERROR][ERROR] For more information about the errors and possible solutions, please read the following articles:[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException[ERROR][ERROR] After correcting the problems, you can resume the build with the command[ERROR]   mvn <goals> -rf :jruby

1、简介      JDK是 Java 语言的软件开发工具包，主要用于移动设备、嵌入式设备上的java应用程序。JDK是整个java开发的核心，它包含了JAVA的运行环境（JVM+Java系统类库）和JAVA工具。官方链接：https://www.oracle.com/technetwork/java/javase/downloads/index.html       类别：工具包2、基础环境类别子项版本获取地址(方法)华为云虚拟机RC3（916）--OSCentOS7.5Kernel4.14软件包Jdk1.8.03、依赖安装无4、组件编译安装此步骤建议在chroot环境下进行，一来对chroot环境可以随意修改，不会影响系统，二来多人共用系统环境，免不了对系统有更改，chroot环境更纯净。1）创建chroot环境,执行后/root/zmm目录下就是个可用的chroot环境，chroot进去即可进行任意操作。yum install --installroot=/root/leiju/ -y basesystem yum rpm-buildmount --bind /dev/ /root/leiju/devmount --bind /proc/ /root/leiju/proc/Chroot环境创建后，进去发现很多基础命令没有，比如vi，需要自行安装对应的rpm包。如下图所示：已可用。其它命令如遇到不可用的，请参考上图的方法添加。2）配置YUM源推荐所有reo源修改为华为开源镜像站，速度更快更稳定。配置参考如下图所示： bash-4.2# grep "huawei" -ri /etc/yum.repos.d//etc/yum.repos.d/CentOS-EPEL.repo:baseurl=https://mirrors.huaweicloud.com/epel/7/aarch64//etc/yum.repos.d/euleros.repo:baseurl=http://mirrors.huaweicloud.com/euler/2.3/os/aarch64//etc/yum.repos.d/euleros.repo:gpgkey=http://mirrors.huaweicloud.com/euler/2.3/os/RPM-GPG-KEY-EulerOS/etc/yum.repos.d/CentOS-Base.repo:baseurl=https://mirrors.huaweicloud.com/centos-altarch/7/os/aarch64//etc/yum.repos.d/CentOS-Base.repo:baseurl=https://mirrors.huaweicloud.com/centos-altarch/7/updates/aarch64//etc/yum.repos.d/CentOS-Base.repo:baseurl=https://mirrors.huaweicloud.com/centos-altarch/7/extras/aarch64//etc/yum.repos.d/CentOS-Base.repo:baseurl=https://mirrors.huaweicloud.com/centos-altarch/7/centosplus/aarch64/3）jdk安装新建并进入存放jdk下载目录mkdir -p /leiju/jdkcd /leiju/jdk下载解压jdk压缩包wget https://download.oracle.com/otn/java/jdk/8u212-b10/59066701cf1a433da9770636fbc4c9aa/jdk-8u212-linux-arm64-vfp-hflt.tar.gz?AuthParam=1561876866_2f2d87400ee6df63d14b9eae0d244553tar zxvf jdk-8u212-linux-arm64-vfp-hflt.tar.gz\?AuthParam\=1561876866_2f2d87400ee6df63d14b9eae0d244553将解压后的jdk目录移到/usr/local/目录下mv jdk1.8.0_212 /usr/local/5、系统配置修改配置文件/etc/profile,在文件最后添加下列配置vi /etc/profile使配置文件立即生效source /etc/profile6、测试测试内容：查看jdk是否安装成功java -version测试结果：安装成功7、参考信息官方参考文档：https://www.oracle.com/technetwork/java/javase/documentation/index.html 8、FQAQ:jdk下载时可能会下载不了?A:需要自己申请个oracle账号，即可正常下载。

在maven中配置了好多jdk是1.6的项目,但是devcloud使用的最低是jdk1.7,这个怎么破?

概览涉及操作系统Huawei JDKOracle JDK应对策略功能Java Web Start（仅win包含）win通过icedtea-web开源软件实现，在itweb-settings.bat进行设置，启动界面不一样，有cmd弹窗原生支持，在java控制面板进行设置正常使用JavaFXwin/linux通过开源OpenJFX实现已将javafx部分开源成OpenJFX社区正常使用applet（过旧，oracle不再继续维护）win/linux不支持支持建议使用javascript等方式进行整改，参考http://3ms.huawei.com/km/groups/3712085/blogs/details/5864289?moduleId=JMC（辅助调试工具）win/linux不支持支持华为HiProfiler补齐功能JFR（问题定位工具）win/linux不支持支持华为HiProfiler补齐功能jvisualvm（问题定位工具）win/linux支持华为HiProfiler补齐功能Java Control Panel（Java控制面板，仅用于win）win不支持支持大多数场景不涉及，建议绕过Java DB（Derby）win/linux不支持8u181版本开始不支持可用GaussDB，大多数场景不涉及，见下一sheetcacerts（默认根证书）win/linux包含93个证书，从SPC050开始提供包含96个证书满足绝大多数场景要求，见下一sheet字体win/linux包含基本字体包含Lucida等8种字体满足绝大多数场景要求JavaAPIwin/linux规格等同8u191规格等同8u191均满足Java标准规范，接口相同兼容性win不支持win 2003/xp支持暂不支持snmpwin/linux不支持支持，但使用范围极小，后续考虑删除绝大多数场景不涉及，建议绕过AWT/Swingwin读取注册表中的BorderWidth和PaddedBorderWidth预设值建议产生影响时调整UI实现。JavaDBJavaDB是一套基于Java编程语言和SQL的关系数据库管理系统。根据Oracle官网的描述，JavaDB是Oracle在Apache Derby项目上发布的二进制版本，且没有修改其源代码。这项功能在OpenJDK中没有对应实现，可选用Apache Derby实现一比一的完全替换  (参考https://db.apache.org/derby/ )OracleJDK在8u181版本中已将JavaDB移除，见 https://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.html

 JDK11新特性说明，请参看附件！

JDK10新特性说明，欢迎参考！

本文附件提供JDK9新特性说明

2019-03-15 14:44:07,109 [WARN] keyStore [server.p12] file not exist, please check! org.apache.servicecomb.foundation.vertx.VertxTLSBuilder.buildTCPSSLOptions(VertxTLSBuilder.java:118)2019-03-15 14:44:07,109 [WARN] trustStore [trust.jks] file not exist, please check! org.apache.servicecomb.foundation.vertx.VertxTLSBuilder.buildTCPSSLOptions(VertxTLSBuilder.java:138)2019-03-15 14:44:07,110 [WARN] keyStore [server.p12] file not exist, please check! org.apache.servicecomb.foundation.vertx.VertxTLSBuilder.buildTCPSSLOptions(VertxTLSBuilder.java:118)2019-03-15 14:44:07,110 [WARN] trustStore [trust.jks] file not exist, please check! org.apache.servicecomb.foundation.vertx.VertxTLSBuilder.buildTCPSSLOptions(VertxTLSBuilder.java:138)2019-03-15 14:44:07,295 [ERROR]  org.apache.servicecomb.foundation.vertx.client.ClientVerticle.start(ClientVerticle.java:38)io.vertx.core.VertxException: ALPN not available for JDK SSL/TLS engineat io.vertx.core.net.impl.SSLHelper.resolveEngineOptions(SSLHelper.java:86)at io.vertx.core.net.impl.SSLHelper.<init>(SSLHelper.java:144)at io.vertx.core.http.impl.HttpClientImpl.<init>(HttpClientImpl.java:133)at io.vertx.core.impl.VertxImpl.createHttpClient(VertxImpl.java:298)at org.apache.servicecomb.foundation.vertx.client.http.HttpClientPoolFactory.createClientPool(HttpClientPoolFactory.java:36)at org.apache.servicecomb.foundation.vertx.client.http.HttpClientPoolFactory.createClientPool(HttpClientPoolFactory.java:27)at org.apache.servicecomb.foundation.vertx.client.ClientPoolManager.createClientPool(ClientPoolManager.java:60)at org.apache.servicecomb.foundation.vertx.client.ClientVerticle.start(ClientVerticle.java:35)at io.vertx.core.AbstractVerticle.start(AbstractVerticle.java:106)at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$8(DeploymentManager.java:483)at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:339)at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:463)at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)at java.lang.Thread.run(Thread.java:748)2019-03-15 14:44:07,315 [ERROR] deploy vertx failed, cause  org.apache.servicecomb.foundation.vertx.VertxUtils.lambda$blockDeploy$0(VertxUtils.java:102)io.vertx.core.VertxException: ALPN not available for JDK SSL/TLS engineat io.vertx.core.net.impl.SSLHelper.resolveEngineOptions(SSLHelper.java:86)at io.vertx.core.net.impl.SSLHelper.<init>(SSLHelper.java:144)at io.vertx.core.http.impl.HttpClientImpl.<init>(HttpClientImpl.java:133)at io.vertx.core.impl.VertxImpl.createHttpClient(VertxImpl.java:298)at org.apache.servicecomb.foundation.vertx.client.http.HttpClientPoolFactory.createClientPool(HttpClientPoolFactory.java:36)at org.apache.servicecomb.foundation.vertx.client.http.HttpClientPoolFactory.createClientPool(HttpClientPoolFactory.java:27)at org.apache.servicecomb.foundation.vertx.client.ClientPoolManager.createClientPool(ClientPoolManager.java:60)at org.apache.servicecomb.foundation.vertx.client.ClientVerticle.start(ClientVerticle.java:35)at io.vertx.core.AbstractVerticle.start(AbstractVerticle.java:106)at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$8(DeploymentManager.java:483)at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:339)at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404)at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:463)at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)at java.lang.Thread.run(Thread.java:748)

在现有平台编解码插件Demo基础上进行开发、制作插件包时，需要先了解普通Java工程和Maven工程的区别。一、Maven工程简介Maven是一个项目管理工具，它包含了一个项目对象模型 (Project Object Model)，一组标准集合，一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。当你使用Maven的时候，你用一个明确定义的项目对象模型来描述你的项目，然后Maven可以应用横切的逻辑，这些逻辑来自一组共享的（或者自定义的）插件。使用Maven构建的Java项目，对源代码、单元测试代码、资源乃至后续需要的文件都有专门的目录规划。Maven工程目录结构如下：src/main/java：储存主要的java代码src/main/resources：储存主要的资源文件，如spring的xml配置文件和log4j的properties文件。src/test/java：储存测试用的类，如JUNIT的测试一般放在这个目录下src/test/resources：储存测试用的资源文件target：存放源代码编译后生成的class文件pom.xml：Maven项目的基础配置文件如果是Web项目，还会有一个src/main/webapp目录，存放Web应用相关代码。以上只是Maven工程的简单介绍，更多资料请自行百度。 二、Maven环境搭建 在导入Maven工程前，需要先搭建好Maven环境。一旦Eclipse中集成了Maven功能，在pom.xml中设置好dependence后，所需的jar包就会自动下载到指定的路径。 配置Maven环境变量在配置Maven环境变量之前，需要先配置好JDK环境变量。Java Development Kit （JDK）版本要求：JDK 1.7及以上版本，建议使用JDK 1.8。Maven插件下载地址：http://maven.apache.org/download.cgi，下载最新版本即可。配置Maven环境变量的具体操作，同配置JDK环境变量。 安装m2e 插件 配置完Maven环境变量后，在Eclipse中选择菜单“help > Eclipse Marketplace...”，在搜索框中输入“maven”，选中搜索结果“Maven Integration for Eclipse”，单击“Install”进行安装即可。 修改JRE为JDK路径安装好m2e插件后，需要在Eclipse中修改Java默认的JRE路径为JDK路径。Step 1  选择“Windows > Preferences > Java > Installed JREs”，将“Installed JREs”框中默认的JRE路径修改为本地JDK安装路径。 Step 2  选择“Installed JREs”菜单下的“Execution Enviroment”项，在弹出的对话框中选择JavaSE版本，同时勾选配套使用的JDK。注意：选择的JavaSE版本必须和本地安装的JDK版本保持一致，建议使用1.8版本。 刷新Maven工程在执行完以上操作后，需要刷新Maven工程，新的配置才会生效。具体操作为：选中Maven工程，单击右键，选择“Maven > Update Project...”，在弹出的对话框中勾选工程名和“Force Update of Snapshots/Releases”，其他选项保持默认，即可刷新工程配置。

问题背景和描述报告 ALPN not available 分两种场景：第一种场景：初始化 HTTP 2 Client 的时候。 CSE (ServiceComb Java Chassis) 默认会初始化 HTTP 2 Client，方便和启用了 HTTP 2 协议的 Provider 进行通信。 io.vertx.core.VertxException: ALPN not available for JDK SSL/TLS engine     at io.vertx.core.net.impl.SSLHelper.resolveEngineOptions(SSLHelper.java:88)     at io.vertx.core.net.impl.SSLHelper.<init>(SSLHelper.java:134)     at io.vertx.core.http.impl.HttpClientImpl.<init>(HttpClientImpl.java:131)     at io.vertx.core.impl.VertxImpl.createHttpClient(VertxImpl.java:317)     at org.apache.servicecomb.foundation.vertx.client.http.HttpClientPoolFactory.createClientPool(HttpClientPoolFactory.java:36)     at org.apache.servicecomb.foundation.vertx.client.http.HttpClientPoolFactory.createClientPool(HttpClientPoolFactory.java:27)     at org.apache.servicecomb.foundation.vertx.client.ClientPoolManager.createClientPool(ClientPoolManager.java:60)     at org.apache.servicecomb.foundation.vertx.client.ClientVerticle.start(ClientVerticle.java:35)     at io.vertx.core.AbstractVerticle.start(AbstractVerticle.java:106)     at io.vertx.core.Verticle.start(Verticle.java:66)     at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$8(DeploymentManager.java:556)这种场景报告的错误在没有使用 HTTP 2 的情况下都可以忽略，不用处理。可以通过下面的配置项关闭 HTTP2 客户端的 ALPN：servicecomb.rest.client.http2.useAlpnEnabled: false如果使用 servicecomb-java-chassis 2.0.2 及其以上版本，还可以使用如下配置项，不初始化 HTTP 2客户端。servicecomb.rest.client.http2.enabled: false第二种场景：初始化 HTTP 2 Server 的时候。 CSE (ServiceComb Java Chassis) 默认不会启用 HTTP 2 Server。 用户需要通过配置项开启 HTTP2， 分为 H2 和 H2C两种模式， 如果使用 H2 模式 ( SSL），必须开启ALPN， 可能报告如下错误。 启用 H2 的配置参考： https://docs.servicecomb.io/java-chassis/zh_CN/transports/http2/io.vertx.core.VertxException: ALPN not available for JDK SSL/TLS engine     at io.vertx.core.net.impl.SSLHelper.resolveEngineOptions(SSLHelper.java:88)     at io.vertx.core.net.impl.SSLHelper.<init>(SSLHelper.java:155)     at io.vertx.core.http.impl.HttpServerImpl.<init>(HttpServerImpl.java:93)     at io.vertx.core.impl.VertxImpl.createHttpServer(VertxImpl.java:308)     at org.apache.servicecomb.transport.rest.vertx.RestServerVerticle.createHttpServer(RestServerVerticle.java:247)     at org.apache.servicecomb.transport.rest.vertx.RestServerVerticle.start(RestServerVerticle.java:99)     at io.vertx.core.Verticle.start(Verticle.java:66)     at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$8(DeploymentManager.java:556)如果使用 H2C 模式， 不需要启用 ALPN，可以通过下面的配置项关闭：servicecomb:     server:       http2:         useAlpnEnabled: false可能原因和解决方案CSE 提供两种方式使用 ALPN， 第一种是 openssl， 第二种是 JDK 原生 SSL。 默认使用原生 SSL， 使用 openssl 需要加上下面的配置项：ssl.engine: openssl在使用 opensssl 时可能的原因* netty 和 boringssl 版本不匹配。或者 netty-tcnative-boringssl-static-*.jar 没有包含对应操作系统的库文件，比如 ARM 环境。 CSE 3.0.0 版本在 foundation-auth 模块包含了 ARM 版本的库文件， 其他环境的库文件在 netty-tcnative-boringssl-static-*.jar 压缩包中。 * 操作系统 openssl 版本过低也可能导致这个问题。 使用 JDK 原生 SSL 时可能的原因* alpn 和 JDK 的版本不匹配，或者没有正确使用安装 ALPN 包。 CSE 默认没有携带 ALPN 包， 需要开发者自行配置。  参考： https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-versions 获取 JDK的对应版本；参考： https://github.com/Blazemeter/jmeter-http2-plugin/blob/master/README.md 了解如何配置。* 本机的JDK版本和操作系统版本位数不一样HTTP2和JDK8配合使用建议JDK8的HTTP2支持不是很好，在实际项目中，发现每次JDK的版本升级，都导致HTTP2支持有些变更，报告一些非常奇怪的错误，给开发者定位带来诸多不便。 如果使用JDK8和HTTP2，建议使用openssl，配置文件中指定：ssl.engine: openssl

【问题描述】 经常有新手朋友在LINUX平台通过编译安装完软件后不知道如何将软件加入PATH路径。以下我们在CentOS7.1以JDK环境变量设置为例进行演示。【解决方法】1. 下载JDK软件包。 通过http://www.oracle.com/technetwork/java/javase/downloads/jdk10-downloads-4416644.html下载jdk-10.0.1_linux-x64_bin.tar.gz。17292 2. 上传jdk-10.0.1_linux-x64_bin.tar.gz到云主机/tmp目录（这里我们使用Filezilla来完成文件上传）。17293 3. 使用root用户登录linux云主机，切换工作路径到/tmp目录，解压jdk-10.0.1_linux-x64_bin.tar.gz到/opt目录。 17294 4. 我们从步骤3可以看到，解压到/opt目录下的JDK为可执行二进制文件，现在我们需要把这些二进制文件的路径加入到$PATH变量里，在这之前我们先看一下当前$PATH变量包含哪些路径。17295 5. JDK环境变量配置方法。部分依赖java的应用程序除需要通过PATH路径找到java相关二进制执行文件外，还依赖JAVA_HOME环境变量。所以我们这在里同时配置JAVA_HOME环境变量，所谓JAVA_HOME就是我们解压出来的jdk-10.0.1文件夹的路径。使用vi打开/etc/profile文件，加入如下两行：export JAVA_HOME=/opt/jdk-10.0.1 export PATH=$PATH:$JAVA_HOME/bin如果想要马上生效，可以执行source /etc/profile执行java命令确认生效。17300正确配置PATH变量后，我们在终端打印出当前变量的值，可以看到PATH变更新增加了jdk二进制可执行文件的路径，同时保留了原来路径。17301