在Feed Mixer里面用到了一個叫做SPR（念“super”）的庫。博文講的就是如何優(yōu)化SPR的java代碼。下面就是他們總結(jié)的優(yōu)化經(jīng)驗。

1. 謹慎對待Java的循環(huán)遍歷

Java中的列表遍歷可比它看起來要麻煩多了。就以下面兩段代碼為例：

A

private final List<Bar> _bars; 
for(Bar bar : _bars) { 
    //Do important stuff 
} 

B

1. private final List<Bar> _bars; 
2. for(int i = 0; i < _bars.size(); i++) { 
3. Bar bar = _bars.get(i); 
4. //Do important stuff 
5. } 

代碼A執(zhí)行的時候 會為這個抽象列表創(chuàng)建一個迭代器，而代碼B就直接使用 get(i) 來獲取元素，相對于代碼A省去了迭代器的開銷。

實際上這里還是需要一些權(quán)衡的。代碼A使用了迭代器，保證了在獲取元素的時候的時間復(fù)雜度是 O(1)（使用了 getNext() 和 hasNext() 方法），最終的時間復(fù)雜度為 O(n) 。但是對于代碼B，循環(huán)里每次在調(diào)用 _bars.get(i) 的時候花費的時間復(fù)雜度為 O(n) (假設(shè)這個list為一個 LinkedList)，那么最終代碼B整個循環(huán)的時間復(fù)雜度就是 O(n^2) (但如果代碼B里面的list是 ArrayList， 那 get(i) 方法的時間復(fù)雜度就是 O(1)了)。所以在決定使用哪一種遍歷的方式的時候，我們需要考慮列表的底層實現(xiàn)，列表的平均長度以及所使用的內(nèi)存。最后因為我們需要優(yōu)化內(nèi)存，再加上 ArrayList 在大多數(shù)情況下查找的時間復(fù)雜度為 O(1) ，最后決定選擇代碼B所使用的方法。

2.在初始化的時候預(yù)估集合的大小

從Java的這篇 文檔我們可以了解到: “一個HashMap 實例有兩個影響它性能的因素：初始大小和加載因子（load factor）。 […] 當(dāng)哈希表的大小達到初始大小和加載因子的乘積的時候，哈希表會進行 rehash操作 […] 如果在一個HashMap 實例里面要存儲多個映射關(guān)系時，我們需要設(shè)置足夠大的初始化大小以便更有效地存儲映射關(guān)系而不是讓哈希表自動增長讓后rehash，造成性能瓶頸。”

在Linkedin實踐的時候，常常碰到需要遍歷一個 ArrayList 并將這些元素保存到 HashMap 里面去。將這個 HashMap 初始化預(yù)期的大小可以避免再次哈希所帶來的開銷。初始化大小可以設(shè)置為輸入的數(shù)組大小除以默認加載因子的結(jié)果值（這里取0.7）：

優(yōu)化前的代碼：

HashMap<String,Foo> _map; 
void addObjects(List<Foo> input) 
{ 
  _map = new HashMap<String, Foo>();  
  for(Foo f: input) 
  { 
    _map.put(f.getId(), f); 
  } 
} 

優(yōu)化后的代碼

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中，所有的方法參數(shù)會在方法調(diào)用之前，只要有方法參數(shù)是一個表達式的都會先這個表達式進行計算（從左到右）。這個規(guī)則會導(dǎo)致一些不必要的操作?？紤]到下面一個場景：使用ComparisonChain比較兩個 Foo 對象。使用這樣的比較鏈條的一個好處就是在比較的過程中只要一個 compareTo 方法返回了一個非零值整個比較就結(jié)束了，避免了許多無謂的比較。例如現(xiàn)在這個場景中的要比較的對象最先考慮他們的score, 然后是 position, 最后就是 _bar 這個屬性了：

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; 
} 
} 

但是上面這種實現(xiàn)方式總是會先生成兩個 String 對象來保存 bar.toString()和other.getBar().toString() 的值，即使這兩個字符串的比較可能不需要。避免這樣的開銷，可以為Bar 對象實現(xiàn)一個 comparator：

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提供了一些工具讓正則表達式盡可能地高效。動態(tài)的正則表達式在實踐中比較少見。在接下來要舉的例子中，每次調(diào)用 String.replaceAll() 都包含了一個常量模式應(yīng)用到輸入值中去。因此我們預(yù)先編譯這個模式可以節(jié)省CPU和內(nèi)存的開銷。

優(yōu)化前：

private String transform(String term) { 
return outputTerm = term.replaceAll(_regex, _replacement);  
} 

優(yōu)化后：

private final Pattern _pattern = Pattern.compile(_regex); 
private String transform(String term) { 
String outputTerm = _pattern.matcher(term).replaceAll(_replacement);  
} 

5. 盡可能地緩存Cache it if you can

將結(jié)果保存在緩存里也是一個避免過多開銷的方法。但緩存只適用于在相同數(shù)據(jù)集撒花姑娘嗎的相同數(shù)據(jù)操作（比如對一些配置的預(yù)處理或者一些字符串處理）?，F(xiàn)在已經(jīng)有多種LRU（Least Recently Used ）緩存算法實現(xiàn)，但是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 特性有時候可以代替緩存來使用。

從這篇文檔，我們可以知道：

“A pool of strings, initially empty, is maintained privately by the class String. When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned. Otherwise, this String object is added to the pool and a reference to this String object is returned”.

這個特性跟緩存很類似，但有一個限制，你不能設(shè)置最多可容納的元素數(shù)目。因此，如果這些intern的字符串沒有限制（比如字符串代表著一些唯一的 id），那么它會讓內(nèi)存占用飛速增長。Linkedin曾經(jīng)在這上面栽過跟頭——當(dāng)時是對一些鍵值使用intern方法，線下模擬的時候一切正常，但一旦 部署上線，系統(tǒng)的內(nèi)存占用一下就升上去了（因為大量唯一的字符串被intern了）。所以最后Linkedin選擇使用 LRU 緩存，這樣可以限制最大元素數(shù)目。

最終結(jié)果

SPR的內(nèi)存占用減少了75%，進而將feed-mixer的內(nèi)存占用減少了 50% (如下圖所示)。這些優(yōu)化減少了對象的生成，進而減少了GC得頻率，整個服務(wù)的延遲就減少了25%。

本文由 greenrobot 翻譯自Linkedin