Java 开发工具 JRebel 和 XRebel 的开发商——Perforce 最近公布了其第九份年度全球 Java 开发者生产力报告，该报告基于对 850 多位 Java 开发者的调查而得出。涵盖的主题包括 Java 团队的性质、他们遇到的挑战，以及首选的开发工具等诸多方面。通过调查发现，尽管有越来越多的开发者使用微服务，但是开发者仍然面临着较长的重新部署时间和服务间的功能问题。

关于受访者

此次调查中 49％ 的受访者是 Java 开发者，6％为董事或副总裁，其余的则是由团队负责人、架构师和顾问组成。其中有超过三分之一（36％）的受访者在大型企业或组织中工作，在中小型公司有 42％，在初创公司有 15％。大多数人都是在小型团队中工作，这表明人们对更敏捷的开发和采用微服务的需求不断增长，在微服务中，开发人员可以使用较少的代码片段。40％ 的团队在 3 至 9 人之间，24％ 在 10-20 人之间，17％ 在 20-50 人之间。

Java 和微服务趋势

不出所料，有 69％ 的受访者仍在使用 Java 8，紧随其后是的 JavaScript 占 40％，以及 Java 11 占36％（在调查中受访者可以选择多种编程语言）。只有 16％ 的受访者表示他们正在使用 Java 12 或更高版本，而目前有 15％ 的受访者仍然在坚持使用 Java 7 或更早期的版本。

对于微服务的采用保持稳定，有 66％ 的受访者正在积极过渡或已经在使用微服务了。只有 13％ 的受访者根本不打算转型。调查中还询问了开发人员在他们主要的应用程序中拥有多少微服务，并以 1 到 20 这种规模进行选择。最终得出的答案是：使用 5-10 的有 36％，使用 1-5 的有 34％，其次是 16％ 使用了 20 或更多的微服务，最后使用 10-20 的占了 14%。当然，公司或组织可以拥有多个应用程序架构，例如：42％ 的用户使用 Monolith、SOA 29%、移动设备 23%，以及桌面设备 18%。

最受欢迎的工具

该报告对受访者在每个类别中最常用的技术和工具也进行了调查：

应用服务器 ——Tomcat 仍占 66％ 的份额。之后，JBoss/WildFly（19％）、WebLogic（18％）、Jetty（15％）和 WebSphere（14％），后几个的占比相对比较均匀。应用程序框架 ——Spring Boot 以 62％ 位居榜首，与去年的 83％ 相比有所下降。DropWizard 的用户占 8％，比 2020 年的 1％ 有所增加。Quarkus 也类似，采用率从 1％ 增加到 6％。框架配置 ——Annotations 以 75％ 的优势居于领先地位。IDE ——IntelliJ IDEA 以 65% 排名第一，其次是 Eclipse（48％）、VSCode（27％）和NetBeans（13％）。JRE/JDK 分发 ——使用 Oracle JDK 开发者有所增加，从去年的 50％ 上升到 59％，尽管有报告指出很多人由于许可成本而放弃使用 JDK。这可能归因于响应此次调查的大型企业的数量占比较高，而大型企业通常比小型组织更难过渡。排名第二的是 AdoptOpenJDK 占 22％，使用 Amazon Corretto 的占比 10％。数据库 ——最受青睐的是数据库是 MySQL 占比 43％，其次是 Oracle DB 和 PostreSQL，分别占36％。接下来是 MongoDB，有 29％ 的受访者在使用。构建工具 ——Maven 以 67％ 的占比成为开发者的首选工具，而去年 Maven 和 Gradle 则是并驾齐驱。虚拟化工具 ——88％ 的受访者表示他们在使用这些工具，而最常见的工具是 Docker，占57％，低于去年的 74％。Kubernetes 以 42％ 的占比排名第二，相比去年的 35％ 有所提高。VMWare 以 27％ 的份额位居第三。CI/CD ——Jenkins 在受访者中使用占比 61％，其他竞争对手（Bamboo、TravisCI 和 TeamCity等），仅占 12％ 或更少。PaaS ——大多数受访者现在正在使用 PaaS 服务提供商，只有 24％ 的受访者表示不使用。对于使用 PaaS 服务提供商的用户，AWS 占 39％ 是用户的首选；Microsoft Azure 紧随其后，占24％；Google Cloud 位居第三，占 18％。开发者的痛点

最严重的应用程序性能问题是较长的应用程序响应时间，达到54％（与去年的55％相提并论）。这种持续的趋势与微服务的采用不断增长相吻合。报告中的另一个性能问题是高 CPU 使用率（39％）和内存泄漏（35％），过多的开放连接和 IO 查询也分别达到26％和19％。

部署时间是最常见的问题。59％ 的开发人员经历了超过四分钟的重新部署时间，而 20％ 经历了超过 10 分钟的重新部署时间。这背后有两个潜在的原因。一种是，随着微服务规模的增长，开发和创建应用程序将花费更长的时间。第二个原因是由于微服务在远程虚拟机上运行。

针对微服务，对服务间功能进行故障排除是报告中最大的挑战，占30％；其次是在本地设置开发环境的问题（占24％）。这可以归因于创建复杂的微服务应用程序的困难度。