最近在刷各大公司的技术博客的时候,我在Linkedin的技术博客上面发现了一篇很不错博文。这篇博文介绍了Linkedin信息流中间层Feed Mixer,它为Linkedin的Web主页,大学主页,公司主页以及客户端等多个分发渠道提供支撑(如下图所示)。 在Feed Mixer里面用到了一个叫做SPR(念“super”)的库。博文讲的就是如何优化SPR的java代码。下面就是他们总结的优化经验。 1. 谨慎对待Java的循环遍历Java中的列表遍历可比它看起来要麻烦多了。就以下面两段代码为例:
代码A执行的时候 会为这个抽象列表创建一个迭代器,而代码B就直接使用 实际上这里还是需要一些权衡的。代码A使用了迭代器,保证了在获取元素的时候的时间复杂度是 O(1) (使用了 所以在决定使用哪一种遍历的方式的时候,我们需要考虑列表的底层实现,列表的平均长度以及所使用的内存。最后因为我们需要优化内存,再加上 2.在初始化的时候预估集合的大小从Java的这篇 文档我们可以了解到: “一个HashMap 实例有两个影响它性能的因素:初始大小和加载因子(load factor)。 […] 当哈希表的大小达到初始大小和加载因子的乘积的时候,哈希表会进行 rehash操作 […] 如果在一个HashMap 实例里面要存储多个映射关系时,我们需要设置足够大的初始化大小以便更有效地存储映射关系而不是让哈希表自动增长让后rehash,造成性能瓶颈。” 在Linkedin实践的时候,常常碰到需要遍历一个
3. 延迟表达式的计算在Java中,所有的方法参数会在方法调用之前,只要有方法参数是一个表达式的都会先这个表达式进行计算(从左到右)。这个规则会导致一些不必要的操作。考虑到下面一个场景:使用 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; } } 但是上面这种实现方式总是会先生成两个 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()); } } } 4. 提前编译正则表达式字符串的操作在Java中算是开销比较大的操作。还好Java提供了一些工具让正则表达式尽可能地高效。动态的正则表达式在实践中比较少见。在接下来要举的例子中,每次调用
5. 尽可能地缓存Cache it if you can将结果保存在缓存里也是一个避免过多开销的方法。但缓存只适用于在相同数据集撒花姑娘吗的相同数据操作(比如对一些配置的预处理或者一些字符串处理)。现在已经有多种LRU(Least Recently Used )缓存算法实现,但是Linkedin使用的是 Guava cache (具体原因见这里) 大致代码如下: private final int MAX_ENTRIES = 1000; private final LoadingCache<String, String> _cache; // Initializing the cache _cache = CacheBuilder.newBuilder().maximumSize(MAX_ENTRIES).build(new CacheLoader<String,String>() { @Override public String load(String key) throws Exception { return expensiveOperationOn(key); } } ); //Using the cache String output = _cache.getUnchecked(input); 6. String的intern方法有用,但是也有危险String 的 intern 特性有时候可以代替缓存来使用。 从这篇文档,我们可以知道:
这个特性跟缓存很类似,但有一个限制,你不能设置最多可容纳的元素数目。因此,如果这些intern的字符串没有限制(比如字符串代表着一些唯一的id),那么它会让内存占用飞速增长。Linkedin曾经在这上面栽过跟头——当时是对一些键值使用intern方法,线下模拟的时候一切正常,但一旦部署上线,系统的内存占用一下就升上去了(因为大量唯一的字符串被intern了)。所以最后Linkedin选择使用 LRU 缓存,这样可以限制最大元素数目。 最终结果SPR的内存占用减少了75%,进而将feed-mixer的内存占用减少了 50% (如下图所示)。这些优化减少了对象的生成,进而减少了GC得频率,整个服务的延迟就减少了25%。 |
|
来自: liuguichuan > 《java》