您將如何聲明OneToMany成員變量

以下哪個聲明是正確選擇分配適當內存量的聲明。方案1的初始收集能力爲0，方案2的初始容量爲10，方案3沒有聲明任何東西。您將如何聲明OneToMany成員變量

如果底層ORM提供程序最終加載這些對象，是不是使用setEmails（..）方法來設置Collection的值。如果是這樣，只要在選項3中聲明這一點是有意義的，這樣我就可以避免不必要的內存分配。

Option 1 
    @OneToMany(mappedBy = "user", cascade = CascadeType.ALL, fetch = FetchType.LAZY) 
    private Set<Email> emails = new HashSet<Email>(0);

或

Option 2 
    @OneToMany(mappedBy = "user", cascade = CascadeType.ALL, fetch = FetchType.LAZY) 
    private Set<Email> emails = new HashSet<Email>();

或

Option 3 
@OneToMany(mappedBy = "user", cascade = CascadeType.ALL, fetch = FetchType.LAZY) 
private Set<Email> emails;

來源

2010-09-01 user339108

選項2具有16的能力在這裏;） – Bozho 2010-09-01 05:44:47

得到了與擁有10 – user339108 2010-09-01 05:48:43

選項默認值爲1的容量，無論出於何種nitpickery它值得一列表困惑，也有容量爲1。（對於常規的Sun HashSet實現） – Affe 2010-09-01 07:08:29

這是microoptimization。

從技術上講，在內存分配方面，他們是有序的：

Option 3優於Option 1略好於Option 2

但儘管如此，Option 2可能是您的最佳選擇

的Set韓元」當你添加項目時，你必須擴展它
你的代碼會更容易處理，因爲你贏了不用爲了檢查null

來源

2010-09-01 05:44:07 Bozho

如果底層的ORM使用setEmails（..）將郵件設置爲延遲加載，它實際上覆蓋了我的初始設置，所以我認爲選項3將是最理想的，因爲我將不會分配任何空間。在這種情況下，您自動擴展的參數不可行 – user339108 2010-09-01 05:47:21

我的應用程序變得越來越慢，我試圖優化其可能性 – user339108 2010-09-01 05:49:43

但是，當您最初創建對象時，您必須在外部初始化它。一個品味的問題。這裏是內存，而不是CPU（緩慢） - 在其他地方尋找問題。 – Bozho 2010-09-01 05:58:42

如果是這樣，這將是有意義的只是把這個聲明爲備選方案3中，讓我能避免不必要的內存分配。

好，你確實也創造實體。而且因爲我喜歡用防守風格的編程方法具有雙向協會工作時，就像這樣：

public void addToEmails(Email email) { 
    emails.add(email); 
    email.setUser(this); 
}

我傾向於選擇方案2，因爲我沒有做空校驗。

說實話，我甚至沒有想到實例化一個空集合的「成本」。這很可能不會導致我的應用程序性能下降。

如果你的應用程序變得很慢（你甚至知道它是爲什麼？它是真的是內存還是GC問題？你診斷或測量了什麼？），我確信有更多的關鍵優化比這個一個要做。其實，我打賭我的襯衫。

而且不要忘記：

如果你無法衡量它，你不能改進它。 --Lord開爾文

來源

2010-09-01 06:12:01

您將如何聲明OneToMany成員變量

回答

相關問題