最近在刷各大公司的技术博客的时候，我在Linkedin的技术博客上面发现了一篇很不错博文。这篇博文介绍了Linkedin信息流中间层Feed Mixer，它为Linkedin的Web主页，大学主页，公司主页以及客户端等多个分发渠道提供支撑（如下图所示）。
在Feed Mixer里面用到了一个叫做SPR（念“super”）的库。博文讲的就是如何优化SPR的java代码。下面就是他们总结的优化经验。
1. 谨慎对待Java的循环遍历 Java中的列表遍历可比它看起来要麻烦多了。就以下面两段代码为例： A: 1 2 3 4 | private final List<Bar> _bars;
for(Bar bar : _bars) {
}
|
B: 1 2 3 4 5 | private final List<Bar> _bars;
for(int i = 0; i < _bars.size(); i++) {
Bar bar = _bars.get(i);
}
|
代码A执行的时候 会为这个抽象列表创建一个迭代器，而代码B就直接使用 get(i) 来获取元素，相对于代码A省去了迭代器的开销。 实际上这里还是需要一些权衡的。代码A使用了迭代器，保证了在获取元素的时候的时间复杂度是 O(1)（使用了 getNext() 和 hasNext() 方法），最终的时间复杂度为 O(n) 。但是对于代码B，循环里每次在调用 _bars.get(i) 的时候花费的时间复杂度为 O(n) (假设这个list为一个 LinkedList)，那么最终代码B整个循环的时间复杂度就是 O(n^2) (但如果代码B里面的list是 ArrayList， 那 get(i) 方法的时间复杂度就是 O(1)了)。所以在决定使用哪一种遍历的方式的时候，我们需要考虑列表的底层实现，列表的平均长度以及所使用的内存。最后因为我们需要优化内存，再加上 ArrayList 在大多数情况下查找的时间复杂度为 O(1) ，最后决定选择代码B所使用的方法。
2.在初始化的时候预估集合的大小 从Java的这篇 文档我们可以了解到: “一个HashMap 实例有两个影响它性能的因素：初始大小和加载因子（load factor）。 […] 当哈希表的大小达到初始大小和加载因子的乘积的时候，哈希表会进行 rehash操作 […] 如果在一个HashMap 实例里面要存储多个映射关系时，我们需要设置足够大的初始化大小以便更有效地存储映射关系而不是让哈希表自动增长让后rehash，造成性能瓶颈。” 在Linkedin实践的时候，常常碰到需要遍历一个 ArrayList 并将这些元素保存到 HashMap 里面去。将这个 HashMap 初始化预期的大小可以避免再次哈希所带来的开销。初始化大小可以设置为输入的数组大小除以默认加载因子的结果值（这里取0.7）： 优化前的代码： 1 2 3 4 5 6 7 8 9 | HashMap<String,Foo> _map;
void addObjects(List<Foo> input)
{
_map = new HashMap<String, Foo>();
for(Foo f: input)
{
_map.put(f.getId(), f);
}
}
|
优化后的代码 1 2 3 4 5 6 7 8 9 | HashMap<String,Foo> _map;
void addObjects(List<Foo> input)
{
_map = new HashMap<String, Foo>((int)Math.ceil(input.size() / 0.7));
for(Foo f: input)
{
_map.put(f.getId(), f);
}
}
|
3. 延迟表达式的计算 在Java中，所有的方法参数会在方法调用之前，只要有方法参数是一个表达式的都会先这个表达式进行计算（从左到右）。这个规则会导致一些不必要的操作。考虑到下面一个场景：使用ComparisonChain比较两个 Foo 对象。使用这样的比较链条的一个好处就是在比较的过程中只要一个 compareTo 方法返回了一个非零值整个比较就结束了，避免了许多无谓的比较。例如现在这个场景中的要比较的对象最先考虑他们的score, 然后是 position, 最后就是 _bar 这个属性了： 1 2 3 4 5 6 7 8 9 10 11 12 13 | public class Foo {
private float _score;
private int _position;
private Bar _bar;
public int compareTo (Foo other) {
return ComparisonChain.start().
compare(_score, other.getScore()).
compare(_position, other.getPosition()).
compare(_bar.toString(), other.getBar().toString()).
result;
}
}
|
但是上面这种实现方式总是会先生成两个 String 对象来保存 bar.toString()和other.getBar().toString() 的值，即使这两个字符串的比较可能不需要。避免这样的开销，可以为Bar 对象实现一个 comparator： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | public class Foo {
private float _score;
private int _position;
private Bar _bar;
private final BarComparator BAR_COMPARATOR = new BarComparator();
public int compareTo (Foo other) {
return ComparisonChain.start().
compare(_score, other.getScore()).
compare(_position, other.getPosition()).
compare(_bar, other.getBar(), BAR_COMPARATOR).
result();
}
private static class BarComparator implements Comparator<Bar> {
@Override
public int compare(Bar a, Bar b) {
return a.toString().compareTo(b.toString());
}
}
}
|
| 
