区分类中重载方法的依据是( )。正确答案: C 你的答案: C (正确)不同的形参名称不同的返回值类型不同的形参列表不同的访问权限题解：两个重载函数必须在下列一个或两个方面有所区别：1、函数的参数个数不同。2、函数的参数类型不同或者参数类型顺序不同

设Tree为已定义的类名，下列语句能正确创建 Tree 对象的是 。正确答案: B 你的答案: B (正确)Tree t=new Tree;Tree t=new Tree();Tree t=Tree();Tree t[ ]=new Tree[10];题解：需要对象，当然只需new一个了，还有别忘了括号。

毕昇 JDK 是华为基于 OpenJDK 优化后的开源版本，是一款高性能、可用于生产环境的 OpenJDK 发行版。毕昇 JDK 稳定运行在华为内部 500 多个产品上，毕昇 JDK 团队积累了丰富的开发经验，解决了许多实际业务中由原生 OpenJDK 缺陷引起的问题。毕昇 JDK 致力于为 Java 开发者提供一款稳定可靠、高性能、易调测的 JDK，也为用户在鲲鹏 AArch64 架构上提供一个更好的选择。本文基于毕昇 JDK8 和毕昇 JDK11 版本特性进行介绍。了解毕昇 JDK毕昇 JDK 是 OpenJDK 的下游，对华为内部一些应用场景上遇到的性能和稳定性问题进行了修复，并针对鲲鹏 AArch64 架构进行了稳定性增强和性能优化，尤其在大数据场景下性能更好。License：采用 GPLv2 with Classpath Exception 协议。支持 Java 版本：目前毕昇 JDK 支持 8 和 11 两个 LTS 版本。支持架构：支持鲲鹏 AArch64 架构，毕昇 JDK 开源代码支持 x86 版本自构建。支持操作系统：目前仅支持 Linux 版本，对操作系统的要求是鲲鹏  AArch64 平台上 glibc 版本不低于 2.17，基本覆盖所有主流操作系统，已验证的 OS 列表，可参考鲲鹏社区产品页的兼容性查询工具。毕昇 JDK 新增特性在 OpenJDK 基础上，毕昇 JDK 在鲲鹏 ARM 架构上进行了性能优化，新增了快速序列化、AppCDS、G1GC 堆内存伸缩、KAE Provider 等特性，充分提升毕昇 JDK 在鲲鹏 ARM 架构下的运行性能。下文将对这四项优势特性进行详细的介绍。快速序列化——提升原生序列化性能问题背景：在一些无法使用 Kyro（无法修改代码时），需要使用 OpenJDK 原生序列化特性的场景，OpenJDK 原生的序列化机制会耗时较长，导致性能较低。毕昇 JDK8&11 通过实行快速序列化特性提升其性能，快速序列化实现原理大致如下图：快速序列化的实现原理通过减少序列化数据字段和提供数据缓存的方式提升 OpenJDK 原生序列化的性能，详细介绍可参考毕昇 JDK 社区快速序列化特性介绍，该特性在毕昇 JDK8&11 都支持。场景建议：业务中序列化/反序列化部分占比较高的场景可以考虑使用。比如：readObject/ writeObject 热点方法占比较高，可以尝试使能该特性。重复对象越多，场景收益越大。实测在某序列化占比较高场景，快速序列化特性较原生序列化性能收益提升15%。使能方法：-XX:+UnlockExperimentalVMOptions-XX:+UseFastSerializer -DfastSerializerEscapeMode=trueAppCDS——提升 java 应用启动速度在 Java 程序运行初始阶段，类的加载是一个比较耗时的过程，且在每次程序运行中均需要执行一遍。而 CDS（Class Data Sharing）技术，就是把类加载后的数据保存到文件中，下次运行时，直接将加载后的类数据从文件中恢复到内存中，不需要再重新执行类的加载过程，从而提高性能。AppCDS 特性在原 CDS 特性基础上增加了对应用类的支持，实现原理如下图所示：AppCDS 的实现原理从实现原理图可以看到，AppCDS 特性通过从 JSA 文件读取共享数据，省略了共享类的加载过程。同时 Shared Memory 支持多进程间共享，也减少对内存的占用。具体使能方式可参考毕昇 JDK 社区关于 AppCDS 特性的使用介绍。G1GC 堆内存伸缩——及时释放空闲堆内存在 OpenJDK 社区的 8u 版本中，即使 G1GC 在空闲堆内存没有被使用时，也不会主动及时归还给 OS，会造成内存资源占用浪费情况。由于 G1 尽可能避免触发 Full GC，因此在许多情况下，除非强制从外部执行 Full GC，否则 G1 不会将空闲的 Java 堆内存释放给操作系统。毕昇 JDK8 通过在 G1 中引入堆内存伸缩特性，在应用程序 CPU 占比不高情况下，定期尝试释放 G1 的空闲堆内存空间给 OS，达到内存资源的最优使用。特性开启后内存释放示意图上图为某业务使能该特性后实测的 JProfile 示意图，可见空闲内存会被平滑释放。在产品线某业务场景下运行 49 个微服务，实测开启 G1 堆内存回收特性比默认 G1GC 的实际物理内存减少 40%。在默认情况下，毕昇 JDK8 不主动开启此功能，对于延迟和吞吐量敏感的业务，不会受到影响。使能方式：-XX:+UseG1GC –XX:+G1UncommitKAE Provider——支持鲲鹏硬加速/提升加解密速度KAE 加解密是鲲鹏加速引擎的加解密模块，鲲鹏硬加速模块实现了 RSA/ SM3/ SM4/ DH/ MD5/ AES等算法，提供了高性能对称加解密、非对称加解密算法能力，兼容 openssl1.1.1a 及其之后版本，支持同步和异步机制。毕昇 JDK 8 通过利用 Provider 机制，实现对鲲鹏服务器 KAE 加解密特性的支持，以帮助用户提升在鲲鹏 AArch64 服务器加解密业务的竞争力，特性实现原理可参考下图，详细介绍可参考毕昇 JDK 社区关于 KAE Provider 特性说明。KAE Provider 特性实现原理该特性在某 web 中间件业务场景中，性能收益较 OpenJDK 原生特性提升90%。支持算法列表：算法说明摘要算法包括 MD5、SHA256、SHA384、SM3对称加密算法 AES支持 ECB、CBC、CTR、GCM 模式对称加密算法 SM4包括 ECB、CBC、CTR、OFB 模式HMac包括 HmacMD5、HmacSHA1、HmacSHA224、HmacSHA256、HmacSHA384、HmacSHA51非对称加解密算法 RSA支持512、1024、2048、3072、4096位秘钥大小DH包括 DHKeyPairGenerator 和 DHKeyAgreement，支持512、1024、2048、3072、4096位秘钥ECDH包括 ECKeyPairGenerator 和 ECDHKeyAgreement，支持曲线secp224r1、prime256v1、secp384r1、secp521r1RSA 签名包括 RSASignature 和 RSAPSSSignature，私钥只支持 RSAPrivateCrtKey其他特性毕昇 JDK 其他特性如：G1GC 支持 Numa-Aware、毕昇 JDK 11 AArch64 版本支持的 ZGC、G1 Full GC 优化、Jmap 支持并行扫描等详情请点击毕昇JDK产品页获取。毕昇 JDK8 和 11 均已开源，并每隔 3 个月进行版本升级和新特性合入，欢迎来毕昇 JDK 开源社区获取最新信息和技术讨论。如果遇到相关技术问题（包括但不限于毕昇 JDK），也可以通过毕昇 JDK 社区进行讨论。原文转载自 华为计算-【鲲鹏 DevKit 黑科技揭秘】┃毕昇 JDK 4大关键特性解读

一个栈的初始状态为空。首先将元素5，4，3，2，1 依次入栈，然后退栈一次，再将元素A,B,C,D依次入栈，之后将所有元素全部退栈，则所有元素退栈（包括中间退栈的元素）的顺序为？A. 1DCAB2345B. 1DCBA2345C. 54321ABCDD. DCBA12345栈的基本特点就是：先进后出，将5，4，3，2，1依次入栈后，再退栈一次，取出的元素就为1，然后A，B，C，D入栈，依次出栈，顺序为DCBA2345，故选B。

1.设一个有序的单链表中有n个结点，现要求插入一个新结点后使得单链表仍然保持有序，则该操作的时间复杂度（）A. O(log2n)B. O(1)C. O(n2)D. O(n)单链表插入不需要移动元素，时间复杂度为O（1），但是要保持有序状态，顺序存取需要按位置访问元素时间复杂度为O（n）,故选D。

Java的发展从1995年开始经历了许多的过程，但是有三个最具有代表性的JDK版本；JDK1.0：标志着java的诞生；JDK1.2：加入了javax.swing组件，这是主要新特性；JDK1.5：标记为tiger，出现了许多一直沿用至今的特性；JDK1.8：Lambda表达式、接口的定义加强已经接触过了一些新特性，例如：自动装箱与拆箱、switch对String的判断支持。

按照官方手册创建截图任务，运行报错如下图，请指点一下，谢谢。参考：https://support.huaweicloud.com/sdkreference-mpc/mpc_05_0053.html

log.info("开始上传文件");ObsClient obsClient = new ObsClient(ak, sk, endPoint);obsClient.putObject(defaultBucketName, pre + dirName + "/" + f.getName(), f);log.info("上传结束");2021-08-06 11:31:02.130  INFO 13816 --- [nPool-worker-27] c.oppein.gltf.controller.GltfController  : 上传结束2021-08-06 11:31:02.130  INFO 13816 --- [nPool-worker-27] c.oppein.gltf.controller.GltfController  : 开始上传文件2021-08-06 11:31:02.130  INFO 13816 --- [nPool-worker-27] com.obs.services.AbstractClient          : Storage|1|HTTP+XML|ObsClient||||2021-08-06 11:31:02|2021-08-06 11:31:02|||0|2021-08-06 11:31:02.130  WARN 13816 --- [nPool-worker-27] com.obs.services.AbstractClient          : [OBS SDK Version=3.21.4];[Endpoint=https://obs.cn-south-1.myhwclouds.com:443/];[Access Mode=Virtul Hosting]2021-08-06 11:31:02.162  INFO 13816 --- [nPool-worker-27] c.o.s.internal.RestStorageService        : OkHttp cost 32 ms to apply http request2021-08-06 11:31:02.162  INFO 13816 --- [nPool-worker-27] c.o.s.internal.RestStorageService        : Storage|1|HTTP+XML|performRequest||||2021-08-06 11:31:02|2021-08-06 11:31:02||[responseCode: 200][request-id: ]|0|2021-08-06 11:31:02.177  INFO 13816 --- [nPool-worker-27] c.o.s.internal.RestStorageService        : write data end, cost 0 ms2021-08-06 11:31:02.177  INFO 13816 --- [nPool-worker-27] c.o.s.internal.RestStorageService        : OkHttp cost 15 ms to apply http request2021-08-06 11:31:02.177  INFO 13816 --- [nPool-worker-27] c.o.s.internal.RestStorageService        : Storage|1|HTTP+XML|performRequest||||2021-08-06 11:31:02|2021-08-06 11:31:02||[responseCode: 200][request-id: 0000017B1983A1B7941995133A0E9EC9]|0|2021-08-06 11:31:02.177  INFO 13816 --- [nPool-worker-27] com.obs.services.AbstractClient          : Storage|1|HTTP+XML|putObject||||2021-08-06 11:31:02|2021-08-06 11:31:02|||0|2021-08-06 11:31:02.177  INFO 13816 --- [nPool-worker-27] com.obs.services.AbstractClient          : ObsClient [putObject] cost 47 ms2021-08-06 11:31:02.177  INFO 13816 --- [nPool-worker-27] com.obs.log.AccessLogger                 : 2021-08-06 11:31:02 130|com.obs.services.AbstractClient|init|78|Storage|1|HTTP+XML|ObsClient||||2021-08-06 11:31:02|2021-08-06 11:31:02|||0|2021-08-06 11:31:02 130|com.obs.services.AbstractClient|init|97|[OBS SDK Version=3.21.4];[Endpoint=https://obs.cn-south-1.myhwclouds.com:443/];[Access Mode=Virtul Hosting]2021-08-06 11:31:02 162|com.obs.services.internal.RestStorageService|executeRequest|553|OkHttp cost 32 ms to apply http request2021-08-06 11:31:02 162|com.obs.services.internal.RestStorageService|performRequest|378|Storage|1|HTTP+XML|performRequest||||2021-08-06 11:31:02|2021-08-06 11:31:02||[responseCode: 200][request-id: ]|0|2021-08-06 11:31:02 177|com.obs.services.internal.RepeatableRequestEntity|writeTo|108|write data end, cost 0 ms2021-08-06 11:31:02 177|com.obs.services.internal.RestStorageService|executeRequest|553|OkHttp cost 15 ms to apply http request2021-08-06 11:31:02 177|com.obs.services.internal.RestStorageService|performRequest|378|Storage|1|HTTP+XML|performRequest||||2021-08-06 11:31:02|2021-08-06 11:31:02||[responseCode: 200][request-id: 0000017B1983A1B7941995133A0E9EC9]|0|2021-08-06 11:31:02 177|com.obs.services.AbstractClient|doActionWithResult|392|Storage|1|HTTP+XML|putObject||||2021-08-06 11:31:02|2021-08-06 11:31:02|||0|2021-08-06 11:31:02 177|com.obs.services.AbstractClient|doActionWithResult|393|ObsClient [putObject] cost 47 ms2021-08-06 11:31:02.193  INFO 13816 --- [nPool-worker-27] c.oppein.gltf.controller.GltfController  : 上传结束2021-08-06 11:31:02.193  INFO 13816 --- [nPool-worker-27] c.oppein.gltf.controller.GltfController  : 开始上传文件2021-08-06 11:31:02.193  INFO 13816 --- [nPool-worker-27] com.obs.services.AbstractClient          : Storage|1|HTTP+XML|ObsClient||||2021-08-06 11:31:02|2021-08-06 11:31:02|||0|2021-08-06 11:31:02.193  WARN 13816 --- [nPool-worker-27] com.obs.services.AbstractClient          : [OBS SDK Version=3.21.4];[Endpoint=https://obs.cn-south-1.myhwclouds.com:443/];[Access Mode=Virtul Hosting]2021-08-06 11:31:02.193  WARN 13816 --- [nPool-worker-27] c.o.s.internal.RestStorageService        : Encountered 1 Internal Server error(s), will retry in 100ms2021-08-06 11:31:02.209 ERROR 13816 --- [o-8089-Acceptor] org.apache.tomcat.util.net.Acceptor      : Socket accept failedjava.io.IOException: 一个封锁操作被对 WSACancelBlockingCall 的调用中断。    at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) ~[na:1.8.0_151]    at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422) ~[na:1.8.0_151]    at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250) ~[na:1.8.0_151]    at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:466) ~[tomcat-embed-core-9.0.33.jar:9.0.33]    at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:72) ~[tomcat-embed-core-9.0.33.jar:9.0.33]    at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:95) ~[tomcat-embed-core-9.0.33.jar:9.0.33]    at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]2021-08-06 11:31:02.209  INFO 13816 --- [ioEventLoop-4-1] io.lettuce.core.protocol.CommandHandler  : null Unexpected exception during request: java.io.IOException: 应用程序没有调用 WSAStartup，或者 WSAStartup 失败。java.io.IOException: 应用程序没有调用 WSAStartup，或者 WSAStartup 失败。    at sun.nio.ch.SocketDispatcher.read0(Native Method) ~[na:1.8.0_151]    at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) ~[na:1.8.0_151]    at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.8.0_151]    at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[na:1.8.0_151]    at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) ~[na:1.8.0_151]    at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253) ~[netty-buffer-4.1.48.Final.jar:4.1.48.Final]    at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1133) ~[netty-buffer-4.1.48.Final.jar:4.1.48.Final]    at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350) ~[netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148) ~[netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:714) [netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650) [netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576) [netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) [netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-common-4.1.48.Final.jar:4.1.48.Final]    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.48.Final.jar:4.1.48.Final]    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.48.Final.jar:4.1.48.Final]    at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]2021-08-06 11:31:02.209  WARN 13816 --- [ioEventLoop-4-1] io.netty.channel.nio.NioEventLoop        : Failed to create a new Selector.io.netty.channel.ChannelException: failed to open a new selector    at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:175) [netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.channel.nio.NioEventLoop.rebuildSelector0(NioEventLoop.java:381) [netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:470) [netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-common-4.1.48.Final.jar:4.1.48.Final]    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.48.Final.jar:4.1.48.Final]    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.48.Final.jar:4.1.48.Final]    at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]Caused by: java.io.IOException: Unable to establish loopback connection    at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:94) ~[na:1.8.0_151]    at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:61) ~[na:1.8.0_151]    at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_151]    at sun.nio.ch.PipeImpl.<init>(PipeImpl.java:171) ~[na:1.8.0_151]    at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:50) ~[na:1.8.0_151]    at java.nio.channels.Pipe.open(Pipe.java:155) ~[na:1.8.0_151]    at sun.nio.ch.WindowsSelectorImpl.<init>(WindowsSelectorImpl.java:127) ~[na:1.8.0_151]    at sun.nio.ch.WindowsSelectorProvider.openSelector(WindowsSelectorProvider.java:44) ~[na:1.8.0_151]    at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:173) [netty-transport-4.1.48.Final.jar:4.1.48.Final]    ... 6 common frames omittedCaused by: java.net.SocketException: Successful WSAStartup not yet performed: socket    at sun.nio.ch.Net.socket0(Native Method) ~[na:1.8.0_151]    at sun.nio.ch.Net.serverSocket(Net.java:415) ~[na:1.8.0_151]    at sun.nio.ch.ServerSocketChannelImpl.<init>(ServerSocketChannelImpl.java:88) ~[na:1.8.0_151]    at sun.nio.ch.SelectorProviderImpl.openServerSocketChannel(SelectorProviderImpl.java:56) ~[na:1.8.0_151]    at java.nio.channels.ServerSocketChannel.open(ServerSocketChannel.java:108) ~[na:1.8.0_151]    at sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(PipeImpl.java:120) ~[na:1.8.0_151]    at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:76) ~[na:1.8.0_151]    ... 14 common frames omitted2021-08-06 11:31:02.209  WARN 13816 --- [ioEventLoop-4-1] io.netty.channel.nio.NioEventLoop        : Unexpected exception in the selector loop.java.io.IOException: 应用程序没有调用 WSAStartup，或者 WSAStartup 失败。    at sun.nio.ch.SocketDispatcher.close0(Native Method) ~[na:1.8.0_151]    at sun.nio.ch.SocketDispatcher.close(SocketDispatcher.java:63) ~[na:1.8.0_151]    at sun.nio.ch.SocketChannelImpl.kill(SocketChannelImpl.java:879) ~[na:1.8.0_151]    at sun.nio.ch.WindowsSelectorImpl.implDereg(WindowsSelectorImpl.java:588) ~[na:1.8.0_151]    at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149) ~[na:1.8.0_151]    at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:142) ~[na:1.8.0_151]    at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) ~[na:1.8.0_151]    at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) ~[na:1.8.0_151]    at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) ~[na:1.8.0_151]    at io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68) ~[netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:803) ~[netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:457) ~[netty-transport-4.1.48.Final.jar:4.1.48.Final]    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-common-4.1.48.Final.jar:4.1.48.Final]    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.48.Final.jar:4.1.48.Final]    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.48.Final.jar:4.1.48.Final]    at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]2021-08-06 11:31:02.273 ERROR 13816 --- [o-8089-Acceptor] org.apache.tomcat.util.net.Acceptor      : Socket accept failedjava.io.IOException: 应用程序没有调用 WSAStartup，或者 WSAStartup 失败。    at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) ~[na:1.8.0_151]    at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422) ~[na:1.8.0_151]    at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250) ~[na:1.8.0_151]    at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:466) ~[tomcat-embed-core-9.0.33.jar:9.0.33]    at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:72) ~[tomcat-embed-core-9.0.33.jar:9.0.33]    at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:95) ~[tomcat-embed-core-9.0.33.jar:9.0.33]    at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]

封装　　所谓的封装就是把类的属性和方法使用private修饰，不允许类的调用者直接访问，我们定义如下一个类，可以看到所有的成员变量和成员方法都使用private修饰了，我们现在来使用一下这个类。　　当我们使用的时候编译器给出了下面这样的报错。　　告诉我们说是private访问控制，那么这是什么意思呢？包可以简单理解为一个文件夹，把类放到放到包里面，也就相当于是专门的文件夹里面。　　ps：稍微记一下这张图中的内容。　　有了上面的基础我们现在再来看private，他的使用范围只有 同一个包中的同一个类中使用（这个范围也就是他的权限），我们就记住只能在我们定义的那个类中使用就好了，别问为什么，因为这就是语法，记住就好了，记准确了是当前类中，不能外部引用，否则就会出现上面那样的报错。既然不能直接从外部引用，那么类的调用者总得有个办法使用吧，不然实现这个类干嘛，这个时候就是我们在设计类的时候要提供的公开的方法了，那么上述的代码应该写成如下形式。　　ps：这里重写了toString方法才会是下面的输出形式。　　上面就是调用了，那么有的读者可能就会问了，那你的eat方法还是private的呀，我还是不能调用啊，这里我解释一下，这是因为我是为了演示private的作用而在eat方法前面加的private，运行时我将它注释掉了，至于实际上像eat这样需要被类的调用者直接使用的方法，肯定是不能使用private修饰的，至于用什么访问权限修饰这就是类的设计者根据日后业务的需要而决定了。　　封装的第一个作用就是为了不直接被外部使用，提高代码的安全性，第二个作用就是降低类的使用者的学习成本，不需要知道类的实现，只需要学会调用就好了，封装差不多就介绍完了，接下来聊聊继承。继承　　所谓继承本质就是实现代码的复用，防止重复的代码多次书写，当一个类继承一个类的时候，该类中就会拥有另外一个类中的所有代码，举个例子看下面代码　　可以看到继承的语法形式是class 子类名 extends 父类名，继承类就是子类，也叫派生类，被继承的类称为父类，基类或者超类（名字一般不做区分，均可使用），语法形式很简单，我们来聊聊其中的细节，首先Java是单继承的， 一个子类只能有一个父类，但是一个子类可以当作另外一个类的父类，即可以B继承A，然后C继承B，代码如下，那么B会拥有A中的代码，C会拥有A、B的代码。　　下面讲的普通类继承知识都是基于父类是公开的并单独位于一个.java文件的。　　我们定义一个这样的Animal类当作父类：　　当访问使用private修饰的属性时就会报错，这个就是上面封装的知识了，只能在定义的类中使用。　　当去掉private不加任何修饰符时为包访问权限（对应上面的default范围，至于default关键字的使用在接口当中会提到），当前包底下的类才能使用Animal中的属性。　　当使用protected修饰时，是可以在子类中调用的，那么下面为什么会报错呢，那是因为调用的方式不对，这里我们需要改变访问方式并使用到super关键字。　　改为如下调用，在子类中调用，并使用super关键字，而不是通过实例化对像调用，上面那张图除了提到包还提到了类，小伙伴们注意到了吗？不记得的小伙伴们就往上翻再看看那张图吧。　　至于public没啥好说的，哪都能用。　　上面呢介绍了继承普通类的知识，现在我们来看看不太正常的类，抽象类，抽象类是指被abstract修饰，包含抽象方法的类，如下就是一个抽象类，首先是类名前面添加了abstract关键字，其次是其中包含了一个抽象方法，什么是抽象方法，就是没有被具体实现的方法，如下图的work方法，没有方法体，并被abstract修饰，不加的话会报错，被abstract修饰的类中可以没有抽象方法，这是语法允许的（jdk1.8测出来的），但是建议同步使用，要么既有abstract修饰类又有abstract方法，要么都没有，不然使用了abstract修饰类又不加abstract方法这不是闹吗，除非你不想这个类直接被实例化，注意一点，abstract修饰的类不能直接被实例化，需要被继承之后通过子类调用父类的构造方法，对从父类继承过来的字段进行初始化，注意这些继承过来的字段和方法都到了子类中了，但是子类能不能使用和如何使用就和给的权限（使用了什么访问修饰符限定）相关了，并没有实例化产生一个父类对象，有些地方说会实例化一个父类对象这是不对的，说一个极端的说法，父类为抽象类你能实例化吗？　　当一个普通类继承一个抽象类的时候需要重写抽象类的所有抽象方法，如果不想重写的话就需要声明为抽象类，看下面代码　　继承主要是为了代码的复用，减少代码的重复书写和为多态打一个基础，接下来我们聊聊多态多态　　多态是一种思想，是同一份代码，不同的传参（子类）调用会产生不同的效果，绝对不是写死的代码　　多态是建立在继承机制上的一种机制，想要了解多态就必须知道向上转型，那么什么是向上转型呢，所谓的向上转型就是使用父类对象的引用，引用子类对象看下面代码　　Teacher是People的一个子类，使用People引用引用一个Teacher对象，向上转型是自动发生的，不需要进行强制类型转换，发生向上转型一般有三种情况　　1.像上面代码一样，让父类引用直接引用子类对象时。　　2.子类作为函数调用时的实参，使用父类形参接收时。　　3.子类作为父类返回值函数的返回值时。　　总的说就是父类引用引用了子类对象　　红色的框表示第二种，橘黄色的框表示第三种　　ps：不难理解吧QAQ　　与向上转型对应的还有向下转型，就是将父类对象赋值给子类引用，一般很少用的，就简单的提一下吧，因为他发生条件比较严格，首先是不能直接强制类型转换，看下面代码（已经将People类变成了类）　　其次是需要父类引用引用子类的对象（发生过向上转型），最后需要强制转换为对应的子类对象，像下面这样　　ps：这东西用起来挺奇怪的，不太建议使用　　到这里相信你应该知道什么叫做向上转型了，但是这还不足以接触多态，我们需要先来聊聊另外一个知识点，动态绑定，所谓动态绑定也叫运行时绑定，我们先来看看代码　　首先可以看到三个输出，第一个输出睡觉，第三个输出教书没问题吧，问题就出在第二个上面，我明明调用的是people的work方法，为什么输出的不是睡觉，而是教书呢？这就是发生了动态绑定，所谓动态绑定就是使用父类引用引用子类对象然后（向上转型）去调用父类和子类相同的方法（返回值（构成父子类关系也可以，也就是协变类型），方法名，形参列表完全相同）换句话说也就是说在子类中重写了父类的方法，这样的重写需要注意一些点，那就是子类重写的方法的访问权限必须不小于父类的方法的权限也就是说父类为public子类就必须为public因为public是最大的权限，权限对应上图的 √ 的个数√越多权限越大，静态方法不能重写，被final修饰的方法（密封方法）不能重写。　　ps：与动态绑定对应的还有静态绑定，这里就不多说了…　　好了，知道了向上转型和动态绑定就可以了解多态了，看代码　　是不是觉得很神奇，明明是指向了同一份代码却打印了不同的结果，这就是多态，我不管你怎么实现的方法，只要你有这个方法我就能帮你调用，并且这里如果是子类对象会发生向上转型，进而发生动态绑定，形成多态，上面是通过继承来实现的多态，接下来我们再来讲一个东西实现多态，接口接口　　那么接口是什么呢，接口也可以想象成一个类，但是它既然单独出现，肯定说明它和类有有所不同，首先接口由interface关键字定义，并且其中的所有方法都默认为public abstract的，所有字段都默认为public static final的，下面几种定义方式并无区别，　　然后类似与继承，接口可以通过implements被实现，实现也很简单，和继承抽象类一样重写所有的抽象方法即可，同样接口不能被直接实例化。　　有了上面的了解，我们来用接口实现多态，看下面代码，也和类实现多态没什么很大区别，也类似与发生了向上转型和动态绑定，实现接口和继承类的一个很大区别就是一个类只能继承一个类，但是一个类可以实现多个接口　　其中接口也可以扩展接口，看下面代码　　从jdk1.8开始接口中可以包含默认方法了需要使用default关键字修饰，和类的成员方法一样，看下面代码，到这里接口就差不多聊完了，小结一下一些建议和小结　　1.建议字段的访问权限能给小绝不给大，能使用private修饰的字段一定要用private，提高安全性。　　2.继承的层次不要太深，建议最多继承三层，使用final修饰可以让类无法被继承。　　3.抽象类的出现就是为了继承之后重写发生动态绑定。　　4.能使用接口就不要使用抽象类，因为类只能单继承，但是接口可以“多继承”，更加的灵活。　　5.多态的核心都是让调用者不必关注对象的具体类型. 这是降低用户使用成本的一种重要方式。　　6.抽象类和接口的核心区别: 抽象类中可以包含普通方法和普通字段, 这样的普通方法和字段可以被子类直接使用(不必重写), 而接口中不能包含普通方法, 子类必须重写所有的抽象方法。　　7.接口中的方法和字段定义都只写必要部分，尽量简洁像博主上面一样

【功能模块】 版本：MRS 3.1.1-LTS 模块：spark模块 可直接联系30004059 任务运行包，不引入任何spark的包【操作步骤&问题现象】1、提交spark任务，任务日志显示java.lang.RuntimeException: java.lang.NoSuchMethodError: org.apache.spark.api.java.JavaPairRDD.flatMapValues(Lorg/apache/spark/api/java/function/Function;)Lorg/apache/spark/api/java/JavaPairRDD;【截图信息】【日志信息】（可选，上传日志内容或者附件）

作者：林军军、彭成寒编者按：笔者在 HBase 业务场景中尝试将 JDK 从 8 升级到 11，使用 G1 GC 作为垃圾回收器，但是性能下降 20%。到底是什么导致了性能衰退？又该如何定位解决？本文介绍如果通过使用 JFR、火焰图等工具确定问题，最后通过版本逐一验证找到了引起性能问题的代码。在毕昇 JDK 中率先修复问题最后将修复推送到上游社区中。希望通过本文的介绍让读者了解到如何解决大版本升级中遇到的性能问题；同时也提醒 Java 开发者要正确地使用参数（使用前要理解参数的含义）。HBase 从 2.3.x 开始正式默认的支持 JDK 11，HBase 对于 JDK 11 的支持指的是 HBase 本身可以通过 JDK 11 的编译、同时相关的测试用例全部通过。由于 HBase 依赖 Hadoop 和 Zookeeper，而目前 Hadoop 和 Zookeeper 尚未支持 JDK 11，所以 HBase 中仍然有一个 jira 来关注 JDK 11 支持的问题：https://issues.apache.org/jira/browse/HBASE-22972。G1 GC 从 JDK 9 以后就成为默认的 GC，而且 HBase 在新的版本中也采用 G1 GC，对于 HBase 是否可以在生产环境中使用 JDK 11？笔者尝试使用 JDK 11 来运行新的 HBase，验证 JDK 11 是否比 JDK 8 有优势。 1      环境介绍验证的方式非常简单，搭建一个 3 节点的 HBase 集群，安装 HBase，采用的版本为 2.3.2，关于 HBase 环境搭建可以参考官网。另外为了验证，使用一个额外的客户端机器，通过 HBase 自带的 PerformanceEvaluation 工具（简称 PE）来验证 HBase 读、写性能。PE 支持随机的读、写、扫描，顺序读、写、扫描等。例如一个简单的随机写命令如下：hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=10000 --valueSize=8000 randomWrite 5该命令的含义是：创建 5 个客户端，并且执行持续的写入测试。每个客户端每次写入 8000 字节，共写入 10000 行。PE 使用起来非常简单，是 HBase 压测中非常流行的工具，关于 PE 更多的用法可以参考相关手册。本次测试为了验证读写性能，采用如下配置：org.apache.hadoop.hbase.PerformanceEvaluation --writeToWAL=true --nomapred --size=256 --table=Test1 --inmemoryCompaction=BASIC --presplit=50 --compress=SNAPPY sequentialWrite 120JDK 采用 JDK 8u222 和 JDK 11.0.8 分别进行测试，当切换 JDK 时，客户端和 3 台 HBase 服务器统一切换。JDK 的运行参数为：-XX:+PrintGCDetails -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:-ResizePLAB注意：这里禁止 ResizePLAB 是业务根据 HBase 优化资料设置。 2      测试结果：JDK 11性能下降通过 PE 进行测试，运行结束有 TPS 数据，表示性能。在相同的硬件环境、相同的 HBase，仅仅使用不同的 JDK 来运行。同时为了保证结果的准确性，多次运行，取平均值。测试结果如下：从表中可以快速地计算得到吞吐量下降，运行时间增加。结论：使用 G1 GC，JDK 11 相对于 JDK 8 来说性能明显下降。3      原因分析从 JDK 8 到 JDK 11， G1 GC 做了非常多的优化用于提高性能。为什么 JDK 11 对于应用者来说更不友好？简单的总结一下从 JDK 8 到 JDK 11 做的一些比较大的设计变化，如下表所示：优化点描述IHOP 启发式设置IHOP 用于控制并发标记的启动时机，在 JDK 9 中引入该优化，根据应用运行的情况，计算 IHOP 的值，确保在内存耗尽之前启动并发标记。对于性能和运行时间理论上都是正优化，特殊情况下可能会导致性能下降Full GC 的并行话在 JDK10 中将 Full GC 从串行实现优化为并行实现，该优化不会产生负面影响动态线程调整根据 GC 工作线程的负载情况，引入动态的线程数来处理任务。该优化会带来正效果，注意不是 GC 工作线程数目越多 GC 的效果越好（GC 会涉及到多线程的任务窃取和同步机制，过多的线程会导致性能下降）引用集的重构引用集处理优化，设置处理大小、将并行修改为并发等由于从 JDK 8 到 JDK 11 特性变化太多，对于这样的性能下降问题，为了能快速有效的解决，我们做了如下的尝试。3.1      统一 JDK 8 和 JDK 11 的参数，验证效果由于 JDK 11 和 JDK 8 实现变化很多，部分功能完全不同，但是这些变化的功能一般都有参数控制，一种有效的尝试：梳理 JDK 8 和 JDK 11 关于 G1 的参数，将它们设置为相同的值，比如关闭 IHOP 的自适应，关闭线程调整等。这里简单的给出 JDK 8 和 JDK 11 不同参数的比较，如下图所示：将两者参数都设置为和 JDK 8 一样的值，重新验证测试，结果不变，JDK 11 性能仍然下降。3.2      GC日志分析，确定JDK 11性能下降点对于 JDK 8 和 JDK 11 同时配置日志收集功能，重新测试，获得 GC 日志。通过 GC 日志分析，我们发现差异主要在 G1 young gc 的 object copy 阶段（耗时基本在这），JDK 11 的 Young GC 耗时大概 200ms，JDK 8 的 Young GC 耗时大概 100ms，两者设置的目标停顿时间都是 100ms。JDK 11 中 GC 日志片段：JDK 8中 GC 日志片段：我们对整个日志做了统计，有以下发现：并发标记时机不同，混合回收的时机也不同；单次 GC 中对象复制的耗时不同，JDK 11 明显更长；总体 GC 次数 JDK 11 的更多，包括了并发标记的停顿次数；总体 GC 的耗时 JDK 11 更多。针对 Young GC 的性能劣化，我们重点关注测试了和 Young GC 相关的参数，例如：调整 UseDynamicNumberOfGCThreads、G1UseAdaptiveIHOP 、GCTimeRatio 均没有效果。下面我们尝试使用不同的工具来进一步定位到底哪里出了问题。3.3      JFR分析-确认日志分析结果毕昇 JDK 11和毕昇 JDK 8 都引入了 JFR，JFR 作为 JVM 中问题定位的新贵，我们也在该案例进行了尝试，关于JFR的原理和使用，参考本系列的技术文章：Java Flight Recorder - 事件机制详解。3.3.1        JDK 11总体信息JDK 8 中通过 JFR 收集信息。3.3.2        JDK 8总体信息JFR 的结论和我们前面分析的结论一致，JDK 11 中中断比例明显高于 JDK 8。3.3.3        JDK 11中垃圾回收发生的情况3.3.4        JDK 8中垃圾回收发生的情况从图中可以看到在 JDK 11 中应用消耗内存的速度更快（曲线速率更为陡峭），根据垃圾回收的原理，内存的消耗和分配相关。 3.3.5        JDK 11中VM操作3.3.6        JDK 8中VM操作通过 JFR 整体的分析，得到的结论和我们前面的一致，确定了 Young GC 可能存在问题，但是没有更多的信息。3.4      火焰图-发现热点为了进一步的追踪 Young GC 里面到底发生了什么导致对象赋值更为耗时，我们使用Async-perf 进行了热点采集。关于火焰图的使用参考本系列的技术文章：使用 perf 解决 JDK8 小版本升级后性能下降的问题。3.4.1        JDK 11的火焰图3.4.2        JDK 11 GC部分火焰图 3.4.3        JDK 8的火焰图3.4.4        JDK 8 GC部分火焰图通过分析火焰图，并比较 JDK 8 和 JDK 11 的差异，可以得到：在 JDK 11 中，耗时主要在：G1ParEvacuateFollowersClosure::do_void()G1RemSet::scan_rem_set 在 JDK 8 中，耗时主要在：G1ParEvacuateFollowersClosure::do_void()更一步，我们对 JDK 11 里面新出现的 scan_rem_set() 进行更进一步分析，发现该函数仅仅和引用集相关，通过修改 RSet 相关参数（修改 G1ConcRefinementGreenZone ），将 RSet 的处理尽可能地从Young GC的操作中移除。火焰图中参数不再成为热点，但是 JDK 11 仍然性能下降。比较 JDK 8 和 JDK 11 中 G1ParEvacuateFollowersClosure::do_void() 中的不同，除了数组处理外其他的基本没有变化，我们将 JDK 11 此处的代码修改和 JDK 8 完全一样，但是性能仍然下降。结论：虽然 G1ParEvacuateFollowersClosure::do_void() 是性能下降的触发点，但是此处并不是问题的根因，应该是其他的原因造成了该函数调用次数增加或者耗时增加。 3.5      逐个版本验证-最终确定问题我们分析了所有可能的情况，仍然无法快速找到问题的根源，只能使用最笨的办法，逐个版本来验证从哪个版本开始性能下降。在大量的验证中，对于 JDK 9、JDK 10，以及小版本等都重新做了构建（关于 JDK 的构建可以参考官网），我们发现 JDK 9-B74 和 JDK 9-B73 有一个明显的区别。为此我们分析了 JDK 9-B73 合入的代码。发现该代码和 PLAB 的设置相关，为此梳理了所有 PLAB 相关的变动：B66 版本为了解决 PLAB size 获取不对的问题（根据 GC 线程数量动态调整，但是开启 UseDynamicNumberOfGCThreads 后该值有问题，默认是关闭）修复了 bug。具体见 jira：Determining the desired PLAB size adjusts to the the number of threads at the wrong placeB74 发现有问题（desired_plab_sz 可能会有相除截断问题和没有对齐的问题），重新修改，具体见 8079555: REDO - Determining the desired PLAB size adjusts to the the number of threads at the wrong placeB115 中发现 B74 的修改，动态调整 PLAB 大小后，会导致很多情况 PLAB 过小（大概就是不走 PLAB，走了直接分配），频繁的话会导致性能大幅下降，又做了修复 Net PLAB size is clipped to max PLAB size as a whole, not on a per thread basis        重新修改了代码，打印 PLAB 的大小。对比后发现 desired_plab_sz 大小，在性能正常的版本中该值为 1024 或者 4096（分别是 YoungPLAB 和 OLDPLAB），在性能下降的版本中该值为 258。由此确认 desired_plab_sz 不正确的计算导致了性能下降。 3.6      PALB 为什么会引起性能下降？PLAB 是 GC 工作线程在并行复制内存时使用的缓存，用于减少多个并行线程在内存分配时的锁竞争。PLAB 的大小直接影响 GC 工作线程的效率。在 GC 引入动态线程调整的功能时，将原来 PLABSize 的大小作为多个线程的总体 PLAB 的大小，将 PLAB 重新计算，如下面代码片段：其中 desired_plab_sz 主要来自 YoungPLABSize 和 OldPLABSIze 的设置。所以这样的代码修改改变了 YoungPLABSize、OldPLABSize 参数的语义。 另外，在本例中，通过参数显式地禁止了 ResizePLAB 是触发该问题的必要条件，当打开 ResizePLAB 后，PLAB 会根据 GC 工作线程晋升对象的大小和速率来逐步调整 PLAB 的大小。注意，众多资料说明：禁止 ResziePLAB 是为了防止 GC 工作线程的同步，这个说法是不正确的，PLAB 的调整耗时非常的小。PLAB 是 JVM 根据 GC 工作线程使用内存的情况，根据数学模型来调整大小，由于模型的误差，可能导致 PLAB 的大小调整不一定有人工调参效果好。如果你没有对 YoungPLABSize、OldPLABSize 进行调优，并不建议禁止 ResizePLAB。在 HBase 测试中，当打开 ResizePLAB 后 JDK 8 和 JDK 11 性能基本相同，也从侧面说明了该参数的使用情况。 3.7      解决方法&修复方法由于该问题是 JDK 9 引入，在 JDK 9, JDK 10, JDK 11, JDK 12, JDK 13, JDK 14, JDK 15, JDK 16 都会存在性能下降的问题。我们对该问题进行了修正，并提交到社区，具体见Jira： https://bugs.openjdk.java.net/browse/JDK-8257145；代码见：https://github.com/openjdk/jdk/pull/1474；该问题在JDK 17中被修复。 同时该问题在毕昇 JDK 所有版本中第一时间得到解决。 当然对于短时间内无法切换 JDK 的同学，遇到这个问题，该如何解决？难道要等到 JDK 17？一个临时的方法是显式地设置 YoungPLABSize 和 OldPLABSize 的值。YoungPLABSize 设置为 YoungPLABSize* ParallelGCThreads，其中 ParallelGCThreads 为 GC 并行线程数。例如 YoungPLABSize 原来为 1024，ParallelGCThreads 为 8，在 JDK 9~16，将 YoungPLABSize 设置为 8192 即可。其中参数 ParallelGCThreads 的计算方法为：没有设置该参数时，当 CPU 个数小于等于 8， ParallelGCThreads 等于 CPU 个数，当 CPU 个数大于 8，ParallelGCThreads 等于 CPU 个数的 5/8）。 3.8      小结本文分享了针对 JDK 升级后性能下降的解决方法。Java 开发人员如果遇到此类问题，可以按照下面的步骤尝试自行解决：对齐不同 JDK 版本的参数，确保参数相同，看是否可以快速重现；分析 GC 日志，确定是否由 GC 引起。如果是，建议将所有的参数重新验证，包括移除原来的参数。本例中一个最大的失误是，在分析过程中没有将原来业务提供的参数 ResizePLAB 移除重新测试，浪费了很多时间。如果执行该步骤后，定位问题可能可以节约很多时间；使用一些工具，比如 JFR、NMT、火焰图等。本例中尝试使用这些工具，虽然无果，但基本上确认了问题点；最后的最后，如果还是没有解决，请联系毕昇 JDK 社区。毕昇 JDK 社区每双周周二举行技术例会，同时有一个技术交流群讨论 GCC、LLVM 和 JDK 等相关编译技术，感兴趣的同学可以添加如下微信小助手入群。原文转载自 openEuler-JDK 从8升级到11，使用 G1 GC，HBase 性能下降近20%。JDK 到底干了什么？

【问题描述】UDF函数目录下短时间产生了大量日志【问题分析】通过分析日志，发现日志中都是Java函数的堆栈，由于前端一直在并行调用java udf 函数，导致大量java堆栈打印到日志文件里。在分析java udf 函数的定义，发现函数有catch (Exception e) {        e.printStackTrace();}当捕获到异常的时候会打印异常堆栈，这个函数会将堆栈输出到日志中。【规避办法】在调用udf函数之前，调试通过再运行，发生错误后及时调整。

尊敬的微认证客户：您好！为帮助您深入了解华为云产品，探索新的技术场景，我们非常高兴地与您分享一个好消息：由华为资深研发团队精心打磨，潜心研发的新微认证《基于MongoDB使用Java实现图书管理系统》将于2021年8月6日正式上线！届时请进入华为云学院-微认证-软件开发查看产品详情，体验使用，我们非常期待您的宝贵建议。以下为该微认证详情，您可提前了解：产品名称: 《基于MongoDB使用Java实现图书管理系统》适合人群：想了解GaussDB(for Mongo)、DevCloud的开发人员及社会大众培训方案：基于GaussDB(for Mongo)、DevCloud，云上部署图书管理系统技术能力：GaussDB(for Mongo)的购买、连接和使用，DevCloud开发过程认证价值：基于GaussDB(for Mongo)、DevCloud实现应用系统的开发届时我们还将开展相关微认证上新活动，详情请关注华为云学院论坛-热门活动相关通知。发布日期：2021年8月3日

作者：冯世杰编者按：Java Flight Recorder（简称为JFR）曾经是Oracle JDK商业版的附属组件，在JDK 11中被正式开始开源，后又被移植到JDK8中。JFR本身对运行期系统的侵入性很小，同时又能提供相对准确和丰富的运行期信息；合理使用该工具可以极大地提高工作效率。本文介绍JFR剖析的事件机制，希望能帮助大家从原理上理解JFR并正确使用JFR。本篇文章中的源码大部分来自openjdk8u262本文出发点是梳理 JFR 的事件机制, 侧重点在于理解而非应用使用上可以不要太过拘泥细节，可以具体问题具体分析。对于JFR我们有着怎样的预期它是一个辅助分析工具，我们希望借助它，尽可能低开销地收集运行时数据，从而辅助对JVM可能存在的故障、性能瓶颈进行分析。我们结合JFR的Goals来看：提供基于生成和消费数据作为事件的API提供缓存机制和二进制数据格式允许配置和过滤事件为OS、JVM、JDK库提供相应的事件从中，我们能粗略地获取这些信息 ：事件以自描述的二进制形式(.jfr)被保存着事件中包含了数据，事件 ≈ 数据.jfr 文件 => read by some Provided API => 重现运行时数据 [ => 可视化]我们想尝试了解JFR的事件驱动机制，具体点就是回答几个问题：一个事件何时产生/启动监控? 经历了怎样的路径? 如何被保存? 保存到哪里? JFR是事件驱动的本节主要是一些前置信息 （假如你有所了解，可以快速浏览或者跳过本节内容）: JVM行为基本都是Event，如类加载对应着Class Load Event, 垃圾回收对应GC Event；Event 主要由 timestamp, event name, additional info, data 这几部分组成。Event 收集四类事件的信息: Instant Event , 发生就收集（e.g. Thread Start ...）Duration Event，持续收集一段时间（e.g. GC Event ...）Timed Event , 收集超过指定时间的事件Sample Event，按频率采样以JFR的Class Load Event为例, 看看一个事件的结构。（共计 24 bytes）<memory address> : 98 80 80 00 87 02 95 ae e4 b2 92 03 a2 f7 ae 9a 94 02 02 01 8d 11 00 00Event Size : 98 80 80 00Event ID : 87 02TimeStamp : 95 ae e4 b2 92 03 Duration : a2 f7 ae 9a 94 02Thread ID : 02Stack trace ID : 01PayLoad（记录的数据，fields 取决于各个 Event 类型）：加载的类 : 8d 11定义类的 ClassLoader : 00 初始化类的 ClassLoader : 00 多个线程都会产生Event，线程通过无锁（Lock-free）设计记录事件。线程将事件首先写入到 ThreadLocalBuffer（简称TLB）,  TLB被填满后，将被转存到 Global buffer（circular），对于较旧的数据，可以通过配置，选择丢弃或者写入磁盘，以便连续保存历史记录。示意图如下所示：注意：TLB、Global Buffer和磁盘文件中的事件记录不会相互备份，未及时转存的数据可能发生丢失，本文不会就这点展开阐述。前置内容已经交代清楚，接着回到正轨。一个事件的生命周期以下是枯燥乏味的一堆代码，但是不得不看。首先来看JFR的结构，如下图所示：肉眼可见的一堆钩子，这些hook用于记录对应的触发事件。我们简单地挑一个 Thread Start 的事件，关注一下它的整个被触发到被记录的过程。在线程创建并执行时会调用记录JFR事件，代码如下：可见当一个新的Java线程被创建时，只要开启了JFR, 那么就会执行上述代码; 接着看一下 on_thread_start 干了什么：在此，我们看到了一个事件EventThreadStart，并且在事件中设置信息后被提交。在 JEP 328中有一个更为简单直接例子，如下：无需太过关心其内容。我们只需关注这个事件生成的结构：这里的 EventType 定义于 jfrEventClass.hpp, 该文件是编译时生成的，简单贴一下生成逻辑，可以参考Makefile文件，如下 （同样无需在意太多细节）: 回到主旋律，继续来看事件的结构和成员函数，如下：其中最为重要的成员函数是 JfrEvent::commit 方法，用于提交事件，代码如下.在函数中，最后一段代码, 也是核心所在，用于真正记录事件：这下，就可以很容易地和第1节的内容对应上了，特别是其中的事件模型的图片：小结用户是否可以自定义一个JFR事件？注意点有哪些？这里通过JEP 328里的例子（稍微有点改动），来展示如何自定义JFR事件。通过编译后直接执行如下命令：> java -XX:StartFlightRecording,filename=event.jfr Test可以得到如下日志信息：Started recording 1. No limit specified, using maxsize=250MB as default.Use jcmd 57980 JFR.dump name=1 to copy recording data to file.日志可以通过标准的API进行解析，下面通过一个简单代码解析上面生成的事件，代码如下：编译运行> java Viewer | less可以得到如下结果。相信此时你已经对JFR的事件机制有了个不错的感觉。实际上JFR的使用一般配合JMC[1]使用，在JMC中通过页面可以得到统计信息，更有助于判断系统的运行情况。后记如果遇到相关技术问题（包括不限于毕昇JDK），可以在论坛求助，也可以进入官网查找所有相关资源（包括二进制下载、代码仓库、使用教学、安装、学习资料等）。毕昇JDK社区每双周周二举行技术例会，同时有一个技术交流群讨论GCC、LLVM、JDK和V8等相关编译技术，感兴趣的同学可以添加如下微信小助手，回复Compiler入群。原文转载自 openEuler-Java Flight Recorder - 事件机制详解参考[1] https://adoptopenjdk.net/jmc.html

经过两个月的学习，相信大家对Java有了进一步的了解和认知我们迎来了第二阶段的最终考核请大家认真阅读考核要求，避免无法考核认证*报名活动才能参加最终考核  点此报名考核截止时间8月09日（超出考核时间不计入成绩）请遵守考试秩序，考试之前请务必仔细阅读以下注意事项：1）正式考试前请确定邮箱已绑定，如未绑定的，请登录华为云官网，按照出现的页面完成邮箱绑定。2）考试请使用Google Chrome（48版本以上）浏览器完成。3）考试次数为5次，请珍惜考试机会。每次考试会从题库中随机抽题。4）考试时间为40分钟，考试期间无法暂停，一旦超时，系统将自动提交试卷。交卷后即可查看到成绩。5）考试共25题，题型包括判断、单选和多选，总分100分。6）考试过程中若有截屏或切屏行为，系统将发出警告，切屏次数达到5次，系统将自动提交试卷7）点击开始考试后，请耐心等待系统抽题，切勿重复刷新页面，否则导致题目抽取错误，成绩将会被作废。集齐三阶段电子证书可获得【Java编程创造营】结业实体证书考核流程点击下方链接进行Java开发技能考核点击进行Java开发技能测评（中级）将成绩截图及最高成绩回复到本帖阶段学习排行榜不仅有学习纪念证书，我们还为参与学习打卡的同学准备了实物奖品奖励通过获取积分，积分排行的方式获得奖励（以下奖励获取需满足积分≥30分）1）学习打卡赢积分学习第二阶段课程：Java面向对象编程：点此学习序号阶段任务详情活动积分奖励附加奖励提交入口1每章随堂测试任务完成方式：在随堂测试打卡帖中，回复对应章节的随堂    回复格式：华为云ID+截图（露出右上角华为云ID，且有效回复次数≥1）2分 /每有效打卡/每章节在提交随堂测试的用户中，抽取1名幸运奖励华为云定制鼠标*1点此前往2每周学习笔记分享任务完成方式：在学习笔记征集帖中，回复本周课程内容的学习笔记    回复格式：华为云ID+笔记内容（字数≥200字）2分 /每有效打卡/每周在本提交学习笔记的用户中，抽取1名幸运奖励华为云定制鼠标*1点此前往3相关文章征集任务完成方式：本学习阶段任意时间内，在“华为云-博客”，发表与学习内容相关的任意原创博客内容，将文章链接回复到指定帖内    回复格式：华为云ID+博客文章链接（字数≥600字）5积分 /每篇有效心得/每阶段 最高10/每阶段每阶段选取1篇最佳博文，奖励机械键盘*1点此前往4问答官排位赛任务完成方式：用户可在相关活动帖中发布自己学习中的疑惑或实践问题，其他用户可参与回答。由专家评审，同一问题下确定一名最佳答案。回复格式：华为云ID+提问的问题/解答答案5积分/每有效问题（最高10分）2积分/每有答复（最高4分）最终会全部每阶段参与互动的用户中，抽取3位幸运奖奖励华为云定制鼠标*1点此前往5完成阶段沙箱实验完成规定的沙箱实验20分/ 沙箱实验/点此前往6完成相关微认证完成规定的微认证并获得微认证证书30分/认证/点此前往注意事项：○获奖名单将在活动结束后3个工作日内公示。如如有异议请于【华为云课程小助手】联系○所有活动奖品将在活动公示后15个工作日内完成发放；○活动奖品颜色、型号随机，且部分奖品数量有限发完即止,,若有缺货或其他情况将替换为同价值的其他奖品；○本次活动回帖内容需满足华为云论坛发帖规范：https://bbs.huaweicloud.com/forum/thread-23077-1-1.html想了解更多关于课程内容请移步主帖：https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=125761