破坏表现

本说明是JPoint 2018会议上我的报告“如何用低效率的代码破坏性能”的书面版本。您可以在会议页面上观看视频和幻灯片。 在时间表中，该报告标有一杯冰沙，因此不会出现任何超级复杂的情况，这对于初学者而言更可能。

报告主题：

• 如何查看代码以在其中找到瓶颈
• 常见的反模式
• 非明显耙
• 耙式旁路

在场外，他们指出了报告中的一些不准确性/遗漏之处，并在此处指出。 也欢迎发表评论。

绩效对绩效的影响

有一个用户类：

class User { String name; int age; } 

我们需要将对象彼此进行比较，因此我们声明equals和hashCode方法：

 import lombok.EqualsAndHashCode; @EqualsAndHashCode class User { String name; int age; } 

该代码是可行的，但问题不同：该代码的性能是否最佳？ 为了回答这个问题，让我们回想一下Object::equals方法的功能：仅当所比较的所有字段都相等时，它才返回正结果，否则结果将为负。 换句话说，一个差异已经足以产生负面结果。

查看为@EqualsAndHashCode生成的代码后@EqualsAndHashCode我们将看到类似以下内容：

 public boolean equals(Object that) { //... if (name == null && that.name != null) { return false; } if (name != null && !name.equals(that.name)) { return false; } return age == that.age; } 

检查字段的顺序与它们声明的顺序相对应，在我们的情况下，这不是最佳解决方案，因为使用equals比较对象比比较简单类型“难”。

好的，让我们尝试使用Idea创建equals/hashCode方法：

 @Override public boolean equals(Object o) { if (this == o) { return true; } if (o == null || getClass() != o.getClass()) { return false; } User that = (User) o; return age == that.age && Objects.equals(name, that.name); } 

一个想法创建了更智能的代码，该代码知道比较不同类型的数据的复杂性。 好吧，我们将@EqualsAndHashCode ，并将显式编写equals/hashCode 。 现在，让我们看看类扩展时会发生什么：

 class User { List<T> props; String name; int age; } 

重新创建equals/hashCode ：

 @Override public boolean equals(Object o) { if (this == o) { return true; } if (o == null || getClass() != o.getClass()) { return false; } User that = (User) o; return age == that.age && Objects.equals(props, that.props) // <---- && Objects.equals(name, that.name); } 

在比较字符串之前先比较列表，这在字符串不同时没有意义。 乍一看并没有太大区别，因为等长字符串通过符号进行比较（即，比较时间随字符串长度的增长而增加）：

 //java.lang.String public boolean equals(Object anObject) { if (this == anObject) { return true; } if (anObject instanceof String) { String anotherString = (String) anObject; int n = value.length; if (n == anotherString.value.length) { char v1[] = value; char v2[] = anotherString.value; int i = 0; while (n-- != 0) { // <---- if (v1[i] != v2[i]) return false; i++; } return true; } } return false; } 

现在考虑比较两个ArrayList （作为最常用的列表实现）。 检查ArrayList ，我们很惊讶地发现它没有自己的equals实现，但是使用了继承的实现：

 //AbstractList::equals public boolean equals(Object o) { if (o == this) { return true; } if (!(o instanceof List)) { return false; } ListIterator<E> e1 = listIterator(); ListIterator<?> e2 = ((List<?>) o).listIterator(); while (e1.hasNext() && e2.hasNext()) { // <---- E o1 = e1.next(); Object o2 = e2.next(); if (!(o1 == null ? o2 == null : o1.equals(o2))) { return false; } } return !(e1.hasNext() || e2.hasNext()); } 

这里重要的是创建两个迭代器并成对通过它们。 假设有两个ArrayList ：

• 从1到99的一个数字
• 从1到100的第二个数字

理想情况下，比较两个列表的大小就足够了，如果它们不重合，立即返回负结果（就像AbstractSet一样），实际上，将执行99个比较，并且仅在十分之一时就可以清楚看出列表是不同的。

Kotlinites有什么？

 data class User(val name: String, val age: Int); 

这里的一切就像龙目岛-比较顺序对应于公告的顺序：

 public boolean equals(Object o) { if (this == o) { return true; } if (o instanceof User) { User u = (User) o; if (Intrinsics.areEqual(name, u.name) && age == u.age) { // <---- return true; } } return false; } 

解决方法是，您可以手动组织字段声明。

让任务复杂化

 void check(Dto dto) { SomeEntity entity = jpaRepository.findOne(dto.getId()); boolean valid = dto.isValid(); if (valid && entity.hasGoodRating()) { // <---- //do smth } } 

该代码包括即使事先可以确定箭头指示的条件的检查结果也要访问数据库。 如果valid变量的值为false，则if块中的代码将永远不会执行，这意味着您可以在没有请求的情况下进行操作：

 void check(Dto dto) { boolean valid = dto.isValid(); if (valid && hasGoodRating(dto)) { //do smth } } //       ,    boolean hasGoodRating(Dto dto) { SomeEntity entity = jpaRepository.findOne(dto.getId()); return entity.hasGoodRating(); } 

没有显式分支的类似示例：

 boolean checkChild(Dto dto) { Long id = dto.getId(); Entity entity = jpaRepository.findOne(id); return dto.isValid() && entity.hasChild(); } 

快速返回可让您延迟请求：

 boolean checkChild(Dto dto) { if (!dto.isValid()) { return false; } return jpaRepository.findOne(dto.getId()).hasChild(); } 

 @Entity class ParentEntity { @ManyToOne(fetch = LAZY) @JoinColumn(name = "CHILD_ID") private ChildEntity child; @Enumerated(EnumType.String) private SomeType type; 

结论：应该按顺序增加操作/检查的顺序，以增加单个操作的复杂性，也许其中某些操作将不必执行。

周期和批量处理

以下示例不需要特殊说明：

 @Transactional void enrollStudents(Set<Long> ids) { for (Long id : ids) { Student student = jpaRepository.findOne(id); // <---- O(n) enroll(student); } } 

由于存在多个数据库查询，因此代码运行缓慢。

修正：

 @Transactional void enrollStudents(Set<Long> ids) { if (ids.isEmpty()) { return; } for (Student student : jpaRepository.findAll(ids)) { enroll(student); } } 

基准测试

关于同一主题的更复杂的示例

 for (Long id : ids) { Region region = jpaRepository.findOne(id); if (region == null) { // <----  region = new Region(); region.setId(id); } use(region); } 

在这种情况下，我们不能用JpaRepository::findAll替换循环， JpaRepository::findAll这将破坏逻辑：从JpaRepository::findAll获得的所有值都不会为null ，并且if块将不起作用。

对于每个数据库密钥，这一事实将帮助我们解决这一难题
返回实际值或不存在的值。 也就是说，从某种意义上说，数据库就是字典。 包装盒中的Java为我们提供了字典的现成实现HashMap在其之上，我们将构建用于替换数据库的逻辑：

 Map<Long, Region> regionMap = jpaRepository.findAll(ids) .stream() .collect(Collectors.toMap(Region::getId, Function.identity())); for (Long id : ids) { Region region = map.get(id); if (region == null) { region = new Region(); region.setId(id); } use(region); } 

反例

 // class Saver @Transactional(propagation = Propagation.REQUIRES_NEW) public void save(List<AuditEntity> entities) { jpaRepository.save(entities); } 

此代码始终创建一个新的事务来保存实体列表。 下垂始于多次调用打开新事务的方法：

 //   @Transactional public void audit(List<AuditDto> inserts) { inserts.map(this::toEntities).forEach(saver::save); // <---- } // class Saver @Transactional(propagation = Propagation.REQUIRES_NEW) // <---- public void save(List<AuditEntity> entities) { jpaRepository.save(entities); } 

解决方案：立即对整个数据集应用Saver::save方法：

 @Transactional public void audit(List<AuditDto> inserts) { List<AuditEntity> bulk = inserts .map(this::toEntities) .flatMap(List::stream) // <---- .collect(toList()); saver.save(bulk); } 

基准测试

具有多个事务的示例很难形式化，这不能说是在循环中调用JpaRepository::findOne 。

该方法不仅适用于数据库，因此Tagir lany Valeev走得更远。 如果更早些，我们这样写：

 List<Long> list = new ArrayList<>(); for (Long id : items) { list.add(id); } 

一切都很好，现在“想法”建议纠正自己：

 List<Long> list = new ArrayList<>(); list.addAll(items); 

但是，即使此选项也不总是令人满意，因为您可以使其更短，更快：

 List<Long> list = new ArrayList<>(items); 

基准测试

从ArrayList删除

 for (int i = from; i < to; i++) { list.remove(from); } 

问题在于实现List::remove方法：

 public E remove(int index) { Objects.checkIndex(index, size); modCount++; E oldValue = elementData(index); int numMoved = size - index - 1; if (numMoved > 0) { System.arraycopy(array, index + 1, array, index, numMoved); // <---- } array[--size] = null; // clear to let GC do its work return oldValue; } 

解决方案：

 list.subList(from, to).clear(); 

但是，如果源代码中使用了远程值，该怎么办？

 for (int i = from; i < to; i++) { E removed = list.remove(from); use(removed); } 

现在，您需要首先浏览清除列表：

 List<String> removed = list.subList(from, to); removed.forEach(this::use); removed.clear(); 

如果您确实要在循环中删除，则更改通过列表的方向将有助于减轻痛苦。 其含义是在清洁单元后移动较少数量的元素：

 //   , . .       for (int i = from; i < to; i++) { E removed = list.remove(from); use(removed, i); } //  , . .    for (int i = to - 1; i >= from; i--) { E removed = list.remove(i); use(removed, reverseIndex(i)); } 

比较所有三种方法（在列下方是大小为100的列表中已删除项目的百分比）：

顺便说一句，有人注意到异常了吗？

 // ArrayList public E remove(int index) { rangeCheck(index); modCount++; E oldValue = elementData(index); int numMoved = size - index - 1; if (numMoved > 0) { // <----     System.arraycopy(elementData, index+1, elementData, index, numMoved); } elementData[--size] = null; // clear to let GC do its work return oldValue; } 

基准测试

结论：批量操作通常比单个操作更快。

范围和表现

此代码不需要任何特殊说明：

 void leaveForTheSecondYear() { List<Student> naughty = repository.findNaughty(); List<Student> underAchieving = repository.findUnderAchieving(); // <---- if (settings.leaveBothCategories()) { leaveForTheSecondYear(naughty, underAchieving); // <---- return; } leaveForTheSecondYear(naughty); } 

我们缩小范围，这给了减号1的查询：

 void leaveForTheSecondYear() { List<Student> naughty = repository.findNaughty(); if (Settings.leaveBothCategories()) { List<Student> underAchieving = repository.findUnderAchieving(); // <---- leaveForTheSecondYear(naughty, underAchieving); // <---- return; } leaveForTheSecondYear(naughty); } 

在这里，细心的读者应该问：静态分析如何？ 为什么Idea不告诉我们表面上的改进？

事实是静态分析的可能性是有限的：如果该方法很复杂（特别是与数据库交互）并且影响了常规状态，那么转移其执行可能会破坏应用程序。 静态分析器能够报告非常简单的执行，例如，在块内的传输不会破坏任何内容。

您可以将变量突出显示用作eratz，但再次使用它时要小心，因为总是可能产生副作用。 您可以使用jetbrains-annotations库中提供的注解@org.jetbrains.annotations.Contract(pure = true)来指示无状态方法：

 // com.intellij.util.ArrayUtil @Contract(pure = true) public static int find(@NotNull int[] src, int obj) { return indexOf(src, obj); } 

结论：过多的工作只会使性能恶化，这种情况常常发生。

最不寻常的例子

 @Service public class RemoteService { private ContractCounter contractCounter; @Transactional(readOnly = true) // <---- public int countContracts(Dto dto) { if (dto.isInvalid()) { return -1; // <---- } return contractCounter.countContracts(dto); } } 

即使不需要事务（此方法的快速返回-1），此实现也会打开事务。

您需要做的就是在需要的地方删除ContractCounter::countContracts内的事务性，然后将其从“外部”方法中删除。

基准测试

结论：控制器和“外向”服务需要摆脱事务性（这不是他们的责任），并且应该删除不需要访问数据库和事务性组件的输入数据验证的整个逻辑。

将日期/时间转换为字符串

永恒的任务之一是将日期/时间转换为字符串。 在八国集团之前，我们这样做：

 SimpleDateFormat formatter = new SimpleDateFormat("dd.MM.yyyy"); String dateAsStr = formatter.format(date); 

随着JDK 8的发布，我们获得了LocalDate/LocalDateTime以及相应的DateTimeFormatter

 DateTimeFormatter formatter = ofPattern("dd.MM.yyyy"); String dateAsStr = formatter.format(localDate); 

让我们衡量一下它的性能：

 Date date = new Date(); LocalDate localDate = LocalDate.now(); SimpleDateFormat sdf = new SimpleDateFormat("dd.MM.yyyy"); DateTimeFormatter dtf = DateTimeFormatter.ofPattern("dd.MM.yyyy"); @Benchmark public String simpleDateFormat() { return sdf.format(date); } @Benchmark public String dateTimeFormatter() { return dtf.format(localDate); } 

问题：假设我们的服务从外部接收数据，我们不能拒绝java.util.Date 。 如果将LocalDate更快地转换为字符串，将Date转换为LocalDate是否对我们有利？ 计算：

 @Benchmark public String measureDateConverted(Data data) { LocalDate localDate = toLocalDate(data.date); return data.dateTimeFormatter.format(localDate); } private LocalDate toLocalDate(Date date) { return date.toInstant().atZone(ZoneId.systemDefault()).toLocalDate(); } 

因此，在使用“九”时，转换Date -> LocalDate有益的。 在G8上，转换成本将吞噬DateTimeFormatter -a的所有好处。

基准测试

结论：利用新的解决方案。

另一个“八”

在这段代码中，我们看到了明显的冗余：

 Iterator<Long> iterator = items // ArrayList<Integer> .stream() .map(Long::valueOf) .collect(toList()) // <----    ? .iterator(); while (iterator.hasNext()) { bh.consume(iterator.next()); } 

我们将其删除：

 Iterator<Long> iterator = items // ArrayList<Integer> .stream() .map(Long::valueOf) .iterator(); while (iterator.hasNext()) { bh.consume(iterator.next()); } 

对不对？ 我在上面已经论证过分的工作会降低性能。 但是在这里，我们删除了多余的部分-并且（突然）情况变得更糟。 要了解正在发生的情况，请使用两个迭代器，并在放大镜下查看它们：

 Iterator iterator1 = items.stream().collect(toList()).iterator(); Iterator iterator2 = items.stream().iterator(); 

第一个迭代器是常规ArrayList$Itr 。

 public boolean hasNext() { return cursor != size; } public E next() { checkForComodification(); int i = cursor; if (i >= size) { throw new NoSuchElementException(); } Object[] elementData = ArrayList.this.elementData; if (i >= elementData.length) { throw new ConcurrentModificationException(); } cursor = i + 1; return (E) elementData[lastRet = i]; } 

第二个更有趣，它是基于ArrayList$ArrayListSpliterator Spliterators$Adapter 。

 // java.util.Spliterators$Adapter public boolean hasNext() { if (!valueReady) spliterator.tryAdvance(this); return valueReady; } public T next() { if (!valueReady && !hasNext()) throw new NoSuchElementException(); else { valueReady = false; return nextElement; } } 

让我们看一下通过async-profiler进行的迭代器迭代：

 15.64% juArrayList$ArrayListSpliterator.tryAdvance 10.67% jusSpinedBuffer.clear 9.86% juSpliterators$1Adapter.hasNext 8.81% jusStreamSpliterators$AbstractWrappingSpliterator.fillBuffer 6.01% oojiBlackhole.consume 5.71% jusReferencePipeline$3$1.accept 5.57% jusSpinedBuffer.accept 5.06% cllbir.IteratorFromStreamBenchmark.iteratorFromStream 4.80% jlLong.valueOf 4.53% cllbiIteratorFromStreamBenchmark$$Lambda$8.885721577.apply 

可以看出，大部分时间都花在了遍历迭代器上，尽管总的来说，我们并不需要它，因为可以这样进行搜索：

 items .stream() .map(Long::valueOf) .forEach(bh::consume); 

Stream::forEach显然是赢家，但这很奇怪：它仍然基于ArrayListSpliterator ，但是其使用已大大改善。

 29.04% oojiBlackhole.consume 22.92% juArrayList$ArrayListSpliterator.forEachRemaining 14.47% jusReferencePipeline$3$1.accept 8.79% jlLong.valueOf 5.37% cllbiIteratorFromStreamBenchmark$$Lambda$9.617691115.accept 4.84% cllbiIteratorFromStreamBenchmark$$Lambda$8.1964917002.apply 4.43% jusForEachOps$ForEachOp$OfRef.accept 4.17% jusSink$ChainedReference.end 1.27% jlInteger.longValue 0.53% jusReferencePipeline.map 

在此配置文件中，大部分时间都花在“吞噬” Blackhole内部的值上。 与迭代器相比，大部分时间直接用于执行Java代码。 可以认为，原因是垃圾回收器的比重比迭代器蛮力低。 检查：

 forEach:·gc.alloc.rate.norm 100 avgt 30 216,001 ± 0,002 B/op iteratorFromStream:·gc.alloc.rate.norm 100 avgt 30 416,004 ± 0,006 B/op 

实际上， Stream::forEach提供了一半的内存消耗。

 // ArrayListSpliterator public void forEachRemaining(Consumer<? super E> action) { int i, hi, mc; // hoist accesses and checks from loop ArrayList<E> lst; Object[] a; if (action == null) throw new NullPointerException(); if ((lst = list) != null && (a = lst.elementData) != null) { if ((hi = fence) < 0) { mc = lst.modCount; hi = lst.size; } else mc = expectedModCount; if ((i = index) >= 0 && (index = hi) <= a.length) { for (; i < hi; ++i) { @SuppressWarnings("unchecked") E e = (E) a[i]; // <---- action.accept(e); } if (lst.modCount == mc) return; } } throw new ConcurrentModificationException(); } 

 Iterator<Long> iterator = items .stream() .map(Long::valueOf) .collect(toList()) .iterator(); while (iterator.hasNext()) { bh.consume(iterator.next()); } 

 items .stream() .map(Long::valueOf) .forEach(bh::consume); 

基准测试

结论：在处理复杂的数据表示时，请做好准备，即使“铁”规则（额外的工作危害）也会停止工作。 上面的示例表明，看似多余的中间列表具有更快实现枚举的优点。

两个技巧

 StackTraceElement[] trace = th.getStackTrace(); StackTraceElement[] newTrace = Arrays .asList(trace) .subList(0, depth) .toArray(new StackTraceElement[newDepth]); // <---- 

引起您注意的第一件事是一个烂的“改进”，即，将一个非零长度的数组传递给Collection::toArray方法。 它详细解释了为什么这样做有害。

第二个问题不是那么明显，并且由于其理解，我们可以在审查者和历史学家的工作之间得出相似之处。

. :

1)
2)
3)

, :

 StackTraceElement[] trace = th.getStackTrace(); StackTraceElement[] newTrace = Arrays.copyOf(trace, depth); //    0 //  StackTraceElement[] newTrace = Arrays.copyOfRange(trace, 0, depth); //   0 

 List<T> list = getList(); Set<T> set = getSet(); return list.stream().allMatch(set::contains); //     ? 

, , :

 List<T> list = getList(); Set<T> set = getSet(); return set.containsAll(list); 

:

 interface FileNameLoader { String[] loadFileNames(); } 

:

 private FileNameLoader loader; void load() { for (String str : asList(loader.loadFileNames())) { // <----   use(str); } } 

, forEach , :

 private FileNameLoader loader; void load() { for (String str : loader.loadFileNames()) { // <----    use(str); } } 

: :

, , , . , : "" ( ), "" ( ), .

→

→