每周精品之编程20190325

 

Java开源项目

 

1.分布式应用服务开发的一站式解决方案 Spring Cloud Alibaba

 

Spring Cloud Alibaba 致力于提供分布式应用服务开发的一站式解决方案。此项目包含开发分布式应用服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

 

依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里分布式应用解决方案，通过阿里中间件来迅速搭建分布式应用系统。

 

地址：https://github.com/spring-cloud-incubator/spring-cloud-alibaba

 

2. JDBC 连接池、监控组件 Druid

 

Druid是一个 JDBC 组件。

 

1.监控数据库访问性能。

 

2.提供了一个高效、功能强大、可扩展性好的数据库连接池。

 

3.数据库密码加密。

 

4.SQL执行日志。

 

地址：https://github.com/alibaba/druid

 

3. Java 的 JSON 处理器 fastjson

 

fastjson 是一个性能很好的 Java 语言实现的 JSON 解析器和生成器，来自阿里巴巴的工程师开发。

 

主要特点：快速FAST (比其它任何基于Java的解析器和生成器更快，包括jackson）；强大（支持普通JDK类包括任意Java Bean Class、Collection、Map、Date或enum）；零依赖（没有依赖其它任何类库除了JDK）。

 

地址：https://github.com/alibaba/fastjson

 

4. 服务框架 Dubbo

 

Apache Dubbo (incubating) |是阿里巴巴的一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

 

地址：https://github.com/alibaba/dubbo

 

5. 企业级流式计算引擎 JStorm

 

JStorm 是参考 Apache Storm 实现的实时流式计算框架，在网络IO、线程模型、资源调度、可用性及稳定性上做了持续改进，已被越来越多企业使用。JStorm 可以看作是 storm 的 java 增强版本，除了内核用纯java实现外，还包括了thrift、python、facet ui。从架构上看，其本质是一个基于 zk 的分布式调度系统。

 

地址：https://github.com/alibaba/jstorm

 

6. apns4j

 

apns4j 是 Apple Push Notification Service 的 Java 实现！

 

地址：https://github.com/teaey/apns4j

 

7. 分布式数据层 TDDL

 

TDDL 是一个基于集中式配置的 jdbc datasource实现，具有主备，读写分离，动态数据库配置等功能。

 

地址：https://github.com/alibaba/tb_tddl

 

8. 轻量级分布式数据访问层 CobarClient

 

Cobar Client是一个轻量级分布式数据访问层（DAL）基于iBatis(已更名为MyBatis)和Spring框架实现。

 

地址：https://github.com/alibaba/cobarclient

 

9. 淘宝定制 JVM：TaobaoJVM

 

TaobaoJVM 基于 OpenJDK HotSpot VM，是国内第一个优化、定制且开源的服务器版Java虚拟机。目前已经在淘宝、天猫上线，全部替换了Oracle官方JVM版本，在性能，功能上都初步体现了它的价值。

 

地址：http://jvm.taobao.org

 

10. Java 图片处理类库 SimpleImage

 

SimpleImage是阿里巴巴的一个Java图片处理的类库，可以实现图片缩略、水印等处理。

 

地址：https://github.com/alibaba/simpleimage

 

11. redis 的 java 客户端 Tedis

 

Tedis 是另一个 redis 的 java 客户端。Tedis 的目标是打造一个可在生产环境直接使用的高可用 Redis 解决方案。

 

地址：https://github.com/justified/tedis

 

12.开源 Java 诊断工具 Arthas

 

Arthas（阿尔萨斯）是阿里巴巴开源的 Java 诊断工具，深受开发者喜爱。

 

Arthas 采用命令行交互模式，同时提供丰富的 Tab 自动补全功能，进一步方便进行问题的定位和诊断。

 

地址：https://alibaba.github.io/arthas/

 

13.动态服务发现、配置和服务管理平台 Nacos

 

 

 

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。

 

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。

 

地址：https://nacos.io/en-us/

 

14.Java 解析 Excel 工具 easyexcel

 

Java 解析、生成 Excel 比较有名的框架有 Apache poi、jxl 。但他们都存在一个严重的问题就是非常的耗内存，poi 有一套 SAX 模式的 API 可以一定程度的解决一些内存溢出的问题，但 POI 还是有一些缺陷，比如 07 版 Excel 解压缩以及解压后存储都是在内存中完成的，内存消耗依然很大。easyexcel 重写了 poi 对 07 版 Excel 的解析，能够原本一个 3M 的 excel 用 POI sax 依然需要 100M 左右内存降低到 KB 级别，并且再大的 excel 不会出现内存溢出，03 版依赖 POI 的 sax 模式。在上层做了模型转换的封装，让使用者更加简单方便。

 

地址：https://github.com/alibaba/easyexcel

 

15.高可用流量管理框架 Sentinel

 

Sentinel 是面向微服务的轻量级流量控制框架，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

 

只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

 

地址：https://github.com/alibaba/Sentinel

 

16.基于多维度 Metrics 的系统度量和监控中间件 SOFALookout

 

Lookout 是一个利用多维度的 metrics 对目标系统进行度量和监控的项目。Lookout 的多维度 metrics 参考 Metrics 2.0 标准。Lookout 项目分为客户端部分与服务器端部分。

 

客户端是一个 Java 的类库，可以将它植入您的应用代码中采集 metrics 信息，客户端更多详情。

 

服务端代码部分，将于下一版本提供。通过 LOOKOUT 的服务，可以对 metrics 数据进行收集、加工、存储和查询等处理，另外结合 grafana，可做数据可视化展示。

 

地址：https://github.com/alipay/sofa-lookout

 

17.基于 Spring Boot 的研发框架 SOFABoot

 

SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等等能力。在增强了 Spring Boot 的同时，SOFABoot 提供了让用户可以在 Spring Boot 中非常方便地使用 SOFAStack 相关中间件的能力。

 

地址：https://github.com/alipay/sofa-boot

 

18.轻量级 Java 类隔离容器 SOFAArk

 

SOFAArk 是一款基于 Java 实现的轻量级类隔离容器，由蚂蚁金服公司开源贡献；主要为应用程序提供类隔离和依赖包隔离的能力；基于 Fat Jar 技术，应用可以被打包成一个自包含可运行的 Fat Jar，应用既可以是简单的单模块 Java 应用也可以是 Spring Boot 应用。可访问网址进入快速开始并获取更多详细信息。

 

地址：https://alipay.github.io/sofastack.github.io/

 

19.分布式链路追踪中间件 SOFATracer

 

SOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 traceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的。这些日志可用于故障的快速发现，服务治理等。

 

地址：https://github.com/alipay/sofa-tracer

 

20.高性能 Java RPC 框架 SOFARPC

 

SOFARPC 是一个高可扩展性、高性能、生产级的 Java RPC 框架。在蚂蚁金服 SOFARPC 已经经历了十多年及五代版本的发展。SOFARPC 致力于简化应用之间的 RPC 调用，为应用提供方便透明、稳定高效的点对点远程服务调用方案。为了用户和开发者方便的进行功能扩展，SOFARPC 提供了丰富的模型抽象和可扩展接口，包括过滤器、路由、负载均衡等等。同时围绕 SOFARPC 框架及其周边组件提供丰富的微服务治理方案。

 

地址：https://github.com/alipay/sofa-rpc

 

21.基于 Netty 的网络通信框架 SOFABolt

 

SOFABolt 是蚂蚁金融服务集团开发的一套基于 Netty 实现的网络通信框架。

 

为了让 Java 程序员能将更多的精力放在基于网络通信的业务逻辑实现上，而不是过多的纠结于网络底层 NIO 的实现以及处理难以调试的网络问题，Netty 应运而生。

 

为了让中间件开发者能将更多的精力放在产品功能特性实现上，而不是重复地一遍遍制造通信框架的轮子，SOFABolt 应运而生。

 

地址：https://github.com/alipay/sofa-bolt

 

22.动态非侵入 AOP 解决方案 JVM-Sandbox

 

JVM-Sandbox，JVM 沙箱容器，一种基于 JVM 的非侵入式运行期 AOP 解决方案。

 

地址：https://github.com/alibaba/jvm-sandbox

 

23.面向云的分布式消息领域标准 OpenMessaging

 

OpenMessaging 是由阿里巴巴发起，与雅虎、滴滴出行、Streamlio 公司共同参与创立，旨在创立厂商无关、平台无关的分布式消息及流处理领域的应用开发标准。

 

地址：https://github.com/openmessaging/openmessaging-java

 

24.P2P 文件分发系统 Dragonfly

 

Dragonfly（蜻蜓）是阿里自研的 P2P 文件分发系统，用于解决大规模文件分发场景下分发耗时、成功率低、带宽浪费等难题。大幅提升发布部署、数据预热、大规模容器镜像分发等业务能力。

 

开源版的 Dragonfly 可用于 P2P 文件分发、容器镜像分发、局部限速、磁盘容量预检等。它支持多种容器技术，对容器本身无需做任何改造，镜像分发比 natvie 方式提速可高达 57 倍，Registry 网络出流量降低99.5%以上。

 

地址：https://github.com/alibaba/Dragonfly

 

25.LayoutManager 定制化布局方案 vlayout

 

VirtualLayout是一个针对RecyclerView的LayoutManager扩展, 主要提供一整套布局方案和布局间的组件复用的问题。

 

地址：https://github.com/alibaba/vlayout

 

26.Java 代码规约扫描插件 P3C

 

项目包含三部分：PMD 实现、IntelliJ IDEA 插件、Eclipse 插件

 

地址：https://github.com/alibaba/p3c

 

 

 

Java开发的性能优化的细节

● 1. 尽量在合适的场合使用单例

使用单例可以减轻加载的负担，缩短加载的时间，提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面：

第一，控制资源的使用，通过线程同步来控制资源的并发访问；

第二，控制实例的产生，以达到节约资源的目的；

第三，控制数据共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。

● 2. 尽量避免随意使用静态变量

当某个对象被定义为static变量所引用，那么GC通常是不会回收这个对象所占有的内存，如

此时静态变量b的生命周期与A类同步，如果A类不会卸载，那么b对象会常驻内存，直到程序终止。

● 3. 尽量避免过多过常地创建Java对象

尽量避免在经常调用的方法，循环中new对象，由于系统不仅要花费时间来创建对象，而且还要花时间对这些对象进行垃圾回收和处理，在我们可以控制的范围内，最大限度地重用对象，最好能用基本的数据类型或数组来替代对象。

● 4. 尽量使用final修饰符

带有final修饰符的类是不可派生的。在JAVA核心API中，有许多应用final的例子，例如java、lang、String，为String类指定final防止了使用者覆盖length()方法。另外，如果一个类是final的，则该类所有方法都是final的。java编译器会寻找机会内联（inline）所有的final方法（这和具体的编译器实现有关），此举能够使性能平均提高50%。

如：让访问实例内变量的getter/setter方法变成”final：

简单的getter/setter方法应该被置成final，这会告诉编译器，这个方法不会被重载，所以，可以变成”inlined”,例子：

● 5. 尽量使用局部变量

调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快；其他变量，如静态变量、实例变量等，都在堆（Heap）中创建，速度较慢。

● 6. 尽量处理好包装类型和基本类型两者的使用场所

虽然包装类型和基本类型在使用过程中是可以相互转换，但它们两者所产生的内存区域是完全不同的，基本类型数据产生和处理都在栈中处理，包装类型是对象，是在堆中产生实例。在集合类对象，有对象方面需要的处理适用包装类型，其他的处理提倡使用基本类型。

● 7. 慎用synchronized，尽量减小synchronize的方法

都知道，实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。synchronize方法被调用时，直接会把当前对象锁了，在方法执行完之前其他线程无法调用当前对象的其他方法。所以，synchronize的方法尽量减小，并且应尽量使用方法同步代替代码块同步。

● 8. 尽量不要使用finalize方法

实际上，将资源清理放在finalize方法中完成是非常不好的选择，由于GC的工作量很大，尤其是回收Young代内存时，大都会引起应用程序暂停，所以再选择使用finalize方法进行资源清理，会导致GC负担更大，程序运行效率更差。

● 9. 尽量使用基本数据类型代替对象

上面这种方式会创建一个“hello”字符串，而且JVM的字符缓存池还会缓存这个字符串；

此时程序除创建字符串外，str所引用的String对象底层还包含一个char[]数组，这个char[]数组依次存放了h,e,l,l,o

● 10. 多线程在未发生线程安全前提下应尽量使用HashMap、ArrayList

HashTable、Vector等使用了同步机制，降低了性能。

● 11. 尽量合理的创建HashMap

当你要创建一个比较大的hashMap时，充分利用这个构造函数

避免HashMap多次进行了hash重构,扩容是一件很耗费性能的事，在默认中initialCapacity只有16，而loadFactor是 0.75，需要多大的容量，你最好能准确的估计你所需要的最佳大小，同样的Hashtable，Vectors也是一样的道理。

● 12. 尽量减少对变量的重复计算

如：

应该改为：

并且在循环中应该避免使用复杂的表达式，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。

● 13. 尽量避免不必要的创建

如：

应该改为：

● 14. 尽量在finally块中释放资源

程序中使用到的资源应当被释放，以避免资源泄漏，这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。

● 15. 尽量使用移位来代替a/b的操作

"/"是一个代价很高的操作，使用移位的操作将会更快和更有效

如：

应该改为：

但注意的是使用移位应添加注释，因为移位操作不直观，比较难理解。

● 16.尽量使用移位来代替a*b的操作

同样的，对于*操作，使用移位的操作将会更快和更有效

如：

应该改为：

● 17. 尽量确定StringBuffer的容量

StringBuffer 的构造器会创建一个默认大小（通常是16）的字符数组。在使用中，如果超出这个大小，就会重新分配内存，创建一个更大的数组，并将原先的数组复制过来，再丢弃旧的数组。在大多数情况下，你可以在创建 StringBuffer的时候指定大小，这样就避免了在容量不够的时候自动增长，以提高性能。

如：

●18. 尽量早释放无用对象的引用

大部分时，方法局部引用变量所引用的对象会随着方法结束而变成垃圾，因此，大部分时候程序无需将局部，引用变量显式设为null。

例如：

Java代码

上面这个就没必要了，随着方法test()的执行完成，程序中obj引用变量的作用域就结束了。但是如果是改成下面：

Java代码

这时候就有必要将obj赋值为null，可以尽早的释放对Object对象的引用。

● 19. 尽量避免使用二维数组

二维数据占用的内存空间比一维数组多得多，大概10倍以上。

● 20. 尽量避免使用split

除非是必须的，否则应该避免使用split，split由于支持正则表达式，所以效率比较低，如果是频繁的几十，几百万的调用将会耗费大量资源，如果确实需要频繁的调用split，可以考虑使用apache的StringUtils.split(string,char)，频繁split的可以缓存结果。

● 21. ArrayList & LinkedList

一个是线性表，一个是链表，一句话，随机查询尽量使用ArrayList，ArrayList优于LinkedList，LinkedList还要移动指针，添加删除的操作LinkedList优于ArrayList，ArrayList还要移动数据，不过这是理论性分析，事实未必如此，重要的是理解好2者得数据结构，对症下药。

● 22. 尽量使用System.arraycopy ()代替通过来循环复制数组

System.arraycopy() 要比通过循环来复制数组快的多。

● 23. 尽量缓存经常使用的对象

尽可能将经常使用的对象进行缓存，可以使用数组，或HashMap的容器来进行缓存，但这种方式可能导致系统占用过多的缓存，性能下降，推荐可以使用一些第三方的开源工具，如EhCache，Oscache进行缓存，他们基本都实现了FIFO/FLU等缓存算法。

● 24. 尽量避免非常大的内存分配

有时候问题不是由当时的堆状态造成的，而是因为分配失败造成的。分配的内存块都必须是连续的，而随着堆越来越满，找到较大的连续块越来越困难。

● 25. 慎用异常

当创建一个异常时，需要收集一个栈跟踪(stack track)，这个栈跟踪用于描述异常是在何处创建的。构建这些栈跟踪时需要为运行时栈做一份快照，正是这一部分开销很大。当需要创建一个 Exception 时，JVM 不得不说：先别动，我想就您现在的样子存一份快照，所以暂时停止入栈和出栈操作。栈跟踪不只包含运行时栈中的一两个元素，而是包含这个栈中的每一个元素。

如果您创建一个 Exception ，就得付出代价，好在捕获异常开销不大，因此可以使用 try-catch 将核心内容包起来。从技术上讲，你甚至可以随意地抛出异常，而不用花费很大的代价。招致性能损失的并不是 throw 操作——尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。真正要花代价的是创建异常，幸运的是，好的编程习惯已教会我们，不应该不管三七二十一就抛出异常。异常是为异常的情况而设计的，使用时也应该牢记这一原则。

● 26. 尽量重用对象

特别是String对象的使用中，出现字符串连接情况时应使用StringBuffer代替，由于系统不仅要花时间生成对象，以后可能还需要花时间对这些对象进行垃圾回收和处理。因此生成过多的对象将会给程序的性能带来很大的影响。

● 27. 不要重复初始化变量

默认情况下，调用类的构造函数时，java会把变量初始化成确定的值，所有的对象被设置成null，整数变量设置成0，float和double变量设置成0.0，逻辑值设置成false。当一个类从另一个类派生时，这一点尤其应该注意，因为用new关键字创建一个对象时，构造函数链中的所有构造函数都会被自动调用。

这里有个注意，给成员变量设置初始值但需要调用其他方法的时候，最好放在一个方法。比如initXXX()中，因为直接调用某方法赋值可能会因为类尚未初始化而抛空指针异常，如：public int state = this.getState()。

● 28. 在java+Oracle的应用系统开发中，java中内嵌的SQL语言应尽量使用大写形式，以减少Oracle解析器的解析负担。

● 29. 在java编程过程中，进行数据库连接，I/O流操作，在使用完毕后，及时关闭以释放资源。因为对这些大对象的操作会造成系统大的开销。

● 30. 过分的创建对象会消耗系统的大量内存，严重时，会导致内存泄漏，因此，保证过期的对象的及时回收具有重要意义。JVM的GC并非十分智能，因此建议在对象使用完毕后，手动设置成null。

● 31. 在使用同步机制时，应尽量使用方法同步代替代码块同步。

● 32. 不要在循环中使用Try/Catch语句，应把Try/Catch放在循环最外层

Error是获取系统错误的类，或者说是虚拟机错误的类。不是所有的错误Exception都能获取到的，虚拟机报错Exception就获取不到，必须用Error获取。

● 33. 通过StringBuffer的构造函数来设定它的初始化容量，可以明显提升性能

StringBuffer的默认容量为16，当StringBuffer的容量达到最大容量时，它会将自身容量增加到当前的2倍+2，也就是2*n+2。无论何时，只要StringBuffer到达它的最大容量，它就不得不创建一个新的对象数组，然后复制旧的对象数组，这会浪费很多时间。所以给StringBuffer设置一个合理的初始化容量值，是很有必要的！

● 34. 合理使用java.util.Vector

Vector与StringBuffer类似，每次扩展容量时，所有现有元素都要赋值到新的存储空间中。Vector的默认存储能力为10个元素，扩容加倍。

vector.add(index,obj) 这个方法可以将元素obj插入到index位置，但index以及之后的元素依次都要向下移动一个位置（将其索引加 1）。 除非必要，否则对性能不利。同样规则适用于remove(int index)方法，移除此向量中指定位置的元素。将所有后续元素左移（将其索引减 1）。返回此向量中移除的元素。所以删除vector最后一个元素要比删除第1个元素开销低很多。删除所有元素最好用removeAllElements()方法。

如果要删除vector里的一个元素可以使用 vector.remove(obj)；而不必自己检索元素位置，再删除，如int index = indexOf（obj）;vector.remove(index)。

● 35. 不用new关键字创建对象的实例

用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用。但如果一个对象实现了Cloneable接口，我们可以调用它的clone()方法。clone()方法不会调用任何类构造函数。

下面是Factory模式的一个典型实现：

改进后的代码使用clone()方法：

● 36. 不要将数组声明为：public static final

● 37. HaspMap的遍历：

利用散列值取出相应的Entry做比较得到结果，取得entry的值之后直接取key和value。

● 38. array(数组)和ArrayList的使用

array 数组效率最高，但容量固定，无法动态改变，ArrayList容量可以动态增长，但牺牲了效率。

●39. 单线程应尽量使用 HashMap, ArrayList,除非必要，否则不推荐使用HashTable,Vector，它们使用了同步机制，而降低了性能。

● 40. StringBuffer,StringBuilder的区别在于

java.lang.StringBuffer 线程安全的可变字符序列。一个类似于String的字符串缓冲区，但不能修改。StringBuilder与该类相比，通常应该优先使用StringBuilder类，因为它支持所有相同的操作，但由于它不执行同步，所以速度更快。

为了获得更好的性能，在构造StringBuffer或StringBuilder时应尽量指定她的容量。当然如果不超过16个字符时就不用了。 相同情况下，使用StringBuilder比使用StringBuffer仅能获得10%~15%的性能提升，但却要冒多线程不安全的风险。综合考虑还是建议使用StringBuffer。

● 41. 尽量使用基本数据类型代替对象。

● 42. 使用具体类比使用接口效率高，但结构弹性降低了，但现代IDE都可以解决这个问题。

● 43. 考虑使用静态方法，如果你没有必要去访问对象的外部，那么就使你的方法成为静态方法。它会被更快地调用，因为它不需要一个虚拟函数导向表。这同时也是一个很好的实践，因为它告诉你如何区分方法的性质，调用这个方法不会改变对象的状态。

● 44. 应尽可能避免使用内在的GET,SET方法。

● 45. 避免枚举，浮点数的使用。

以下举几个实用优化的例子：

● 一、避免在循环条件中使用复杂表达式

在不做编译优化的情况下，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。例子：

更正：

● 二、为Vectors 和 Hashtables定义初始大小

JVM为Vector扩充大小的时候需要重新创建一个更大的数组，将原原先数组中的内容复制过来，最后，原先的数组再被回收。可见Vector容量的扩大是一个颇费时间的事。

通常，默认的10个元素大小是不够的。你最好能准确的估计你所需要的最佳大小。例子：

更正：

自己设定初始大小。

● 三、在finally块中关闭Stream

程序中使用到的资源应当被释放，以避免资源泄漏。这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。

● 四、使用System.arraycopy ()代替通过来循环复制数组

例子：

更正：

● 五、让访问实例内变量的getter/setter方法变成”final”

简单的getter/setter方法应该被置成final，这会告诉编译器，这个方法不会被重载，所以，可以变成”inlined”,例子：

● 六、对于常量字符串，用String 代替 StringBuffer

常量字符串并不需要动态改变长度。

例子：

更正：把StringBuffer换成String，如果确定这个String不会再变的话，这将会减少运行开销提高性能。

● 七、在字符串相加的时候，使用   代替 " "，如果该字符串只有一个字符的话

例子：

更正：

将一个字符的字符串替换成

 

程序员如何精确评估开发时间？

评估开发时间的重要性

首先，在一个项目中，所有的环节都是承上启下的，上一个环节结束的时间节点正是下一个环节开始的节点。那么在一个项目或者一次迭代正式启动前，所有的环节都应该有个时间评估。以一次APP需求迭代为例，项目计划像这样：

UI设计图   11.01 - 11.03（3工作日）

API接口讨论与设计 11.04（1工作日）

移动端开发 11.05 - 11.15（8工作日）

后端具备联调条件：11.11

产品体验 11.16 - 11.17（2工作日）

测试11.18 - 11.25（5工作日）

发布11.26

 

开发时间评估，最大的好处是程序员受益。认真地评估开发时间，会让你在开始动手写代码之前搞清楚要怎么写，每个模块的设计心理得有个谱。从宏观上拆分模块，然后详细地分解任务，具体到一个很小的功能点。这样你就能清晰地设计代码，而不是堆代码。也避免了很多时候写着写着发现不对，然后拉倒重来的境地。就是要让你动手写代码之前胸有成竹！

初学者为什么评估不准？

如果你的项目经常delay，那么八成是时间评估不准。

刚毕业的学生被问到什么时候可以完成的时候，脑门一拍：“三天”，实际上两个星期过去了还没完成。

这里有一张表，看看你是不是这样子，对号入座：

越是老程序员越是“胆小”，评估时间越准。

如何精确评估开发时间

最近几年，我都是以小时为单位进行时间评估的，有没有觉得有点恐怖？长期以来这样的习惯让我收获颇多。这得感谢我之前的领导，三年前强迫我们这样做，刚开始很抵触，后来才体会到其中的甜头。

1. 任务拆分

拿到新需求后，对其进行充分了解，不清楚的就去问清楚，然后对其进行模块化。之后，再进行技术上的拆分。由大到小，再到细节。细到什么程度呢？细到一个按钮的实现，细到一个点击动作是要用按钮还是要用手势的定夺，最好能细到代码块的划分。

这个能力是需要锻炼的，做好拆分，然后在实际开发过程中根据实际时间花销，回顾时间评估的准确性，以便让下次更准确。慢慢地，就会越来越精确，评估时间有依有据，不再是拍脑门给出的时间。下面看一个例子：

2. 合理认知时间

一天工作八小时，但你不可能专注地连续八小时在编写代码。一天的工作中，有开会、讨论、阶段性休息（刷新闻、喝咖啡、发呆）的时间开销，真正有效时间其实不足六小时，杂事多的话可能是四五个小时。

3. 预留buffer(缓冲区)

首先明确，预留buffer不是让你随便增加预估量，而是要明确知道buffer是给那些事情用的。要考虑到以下几点：

首先是沟通时间，你开发的时候不可能是闷着头一直写代码。要和UI设计师沟通，要和产品经理沟通，有可能还需要和组内的人沟通技术上的事情，以及和别的技术小组对接的问题。

等待时间。如果牵扯多部门协作，会有很多等待时间，因为你不能保证别的部门就能准确按照计划时间完成的。虽然等待过程中你可以安排其他任务，但你不能保证其他任务就能刚好填充等待时间，更何况任务切换也需要时间成本。

突发状况。例如，bug修改、需求微调、对接人请假。

不确定时间。和其他部门有交集的工作，最好多预留buffer。比如移动端和后台联调。后端信誓旦旦给你说11.11号可以进行联调，这次联调总共5个接口。如果你简单地认为他们给你提供的接口没问题，并且能顺利请求回来数据，预计一天联调时间足以，那你就等着delay吧。11.10号你已经准备好了所有联调准备，如果数据能正确返回，你的解析功能都是OK的，因为你之前用假数据已经处理得好好的。到了11号，你请求第一个接口就报错了，然后在即时通讯软件上问他们怎么回事，半个小时后给你回了“不好意思，地址变了，你用这个试试”。又错了……。终于回来数据了，然后发现缺少两个字段……。就这样，第一个接口调通已经快下班了。（当然很多后端技术人员也是很靠谱的，举这个例子只是为了让多考虑）

以上是可能会出现的状况，实际中有可能只是出现了一部分，这要根据实际情况而定。并不是让你能多预留buffer就多留，毕竟每个项目的时间都是很紧张的。一般buffer留在15%-25%。

4. 回头看

在实际开发过程中，测量实际花费时间，并与估算相比较。如果有些地方相差较大，就要看差在哪里，然后在下次预估中避免相同的差错。

 

总结

编程经验不等同于估算经验。一个不被包含在估算流程中的开发者将不会擅长估算。同样，如果实际的时间花费不被测量和用于与估算比较，那么将没有反馈来学习。

最后，每个程序员都应该具备估算的技能。为磨练这个技能，接手每个任务时，先决定你要做什么。然后在开始之前估算任务所需时间。最后测量实际花费时间，并与估算相比较。同样比较你实际完成的与计划完成的。这样你将会既提高你对一个任务包含细节的理解，同样也提高了你的估算技能。

尽管进行了精确估算，也不能保证每个项目都会100%精确。偶尔会遇到一些突发情况和没预估到的风险是不可避免的。那么面对风险，有一些原则可以帮助你：

报风险时间置前，如果开发开始或者任何过程有可能导致项目延期或者需求无法实现的时候就报警，不要等加班能实现或者存在侥幸心理；

对于不确定的需求，一定要沟通到位；

涉及到交互细节，必须提前沟通好，充分明确细节；

技术可行性方案提前调查清楚。

 

 

分享资源：

《Java面试突击》

链接：https://pan.baidu.com/s/1qVIO_J_xnM6wzDchce94nw 提取码：zuua