這是“ 影子字段與屬性訪問器”界面的 第3輪 。 如果您是新手，但不確定要怎么做，請查看我以前的文章或關(guān)于開發(fā)JavaFX應(yīng)用程序時(shí)節(jié)省內(nèi)存的第一篇文章 。 作為Java開發(fā)人員，我主要關(guān)心的是在開發(fā)JavaFX域模型時(shí)在性能 ， 內(nèi)存使用和降低樣板代碼（易于使用API??）之間取得良好的平衡。 通常，應(yīng)用程序框架提供模型視圖控制器（MVC）或表示模型模式以將UI代碼與域?qū)ο蠓珠_。 實(shí)際上，想到的是域模型類型對象應(yīng)該易于創(chuàng)建或生成（ IDE ）。 在此博客條目中，您將看到第3輪的結(jié)果，其中包括兩個(gè)部分 。 第1部分是使用Marcel Heckel的想法實(shí)施的，第2部分是我最終根據(jù)性能 ， 內(nèi)存使用和易用性實(shí)現(xiàn)的一種實(shí)現(xiàn)。

• 免責(zé)聲明：使用任何代碼均需自擔(dān)風(fēng)險(xiǎn)。 這純粹是實(shí)驗(yàn)性的，不應(yīng)在生產(chǎn)中使用。 這是一個(gè)進(jìn)展中的工作。

最新的代碼在這里—> [ PropertyAccessors接口 ]

第二輪回顧

盡管上一輪（ 第2輪 ）表明我的Property Accessors策略在內(nèi)存消耗方面比標(biāo)準(zhǔn)（fat）特性對象策略稍微好一點(diǎn)，但是當(dāng)創(chuàng)建2,000,000個(gè)具有本地類型的Employee類型類的對象時(shí)，它在性能方面仍然令人失望輸入對象 。 與Dirk的實(shí)現(xiàn)相比，我對第二輪實(shí)現(xiàn)的內(nèi)存使用仍然不滿意。 如果您只關(guān)心我在第3輪中的最終成績，請?zhí)痢?結(jié)果”部分。

因?yàn)?#xff0c;可能會有新的回合，如果您決定使用它，或者假設(shè)Dirk決定在此處接受我的拉取請求，請轉(zhuǎn)到此處查看當(dāng)前代碼。

在第2輪中，我使用了一個(gè)哈希映射查找，因?yàn)殡S著O（1）時(shí)間復(fù)雜度（搜索）越來越多地添加了越來越多的字段，它的查找速度可能會非常慢。 有趣的是，Marcel Heckel提出了一種創(chuàng)建對象索引數(shù)組的簡單方法，該方法不僅可以節(jié)省更多內(nèi)存，而且速度更快。 與鍵/值對查找相比，直接訪問字段絕對是必經(jīng)之路。 盡管Marcel的代碼速度更快，但它仍然比Dirk的Shadow Fields代碼占用更多的內(nèi)存。 額外的內(nèi)存實(shí)際上是通過預(yù)分配一個(gè)數(shù)組來占用的，該數(shù)組將保存每個(gè)字段的值。 即使它們?nèi)珵?strong>空 ，也會為每個(gè)員工對象創(chuàng)建數(shù)組本身。 我在這里實(shí)施了Marcel的策略（第23行）。 讓我們看一下索引字段數(shù)組策略的結(jié)果。

第1部分：使用索引字段數(shù)組

private final Object[] modelProperties =new Object[FIELDS.values().length];public Object[] getModelProperties(){return modelProperties;}

測試：對象不使用屬性字段

下面顯示的是混合使用Marcel的索引數(shù)組思想和我使用枚舉類型指定屬性名稱以將字段表示為屬性字段的方式。

與所有字段均作為JavaFX屬性的標(biāo)準(zhǔn)（胖）對象相比，未使用JavaFX屬性的對象。 此實(shí)現(xiàn)對每個(gè)字段使用數(shù)組索引，并使用數(shù)組保存每個(gè)值。

在上方，您會注意到未選中該復(fù)選框，以指示不要在域?qū)ο笊蟿?chuàng)建JavaFX 屬性 （ 不使用xxxxProperty（）方法 ）。 您會注意到，與第二回合的代碼相比，性能得到了顯著提高，并且內(nèi)存使用量也減少了。 在上圖中， Property Accessor界面比Shadow Fields的模式實(shí)現(xiàn)多了16MB 。 在瘦對象??性能和內(nèi)存使用的第1部分中， Shadow Fields是明顯的贏家。 但是，Shadow Fields仍然不太干凈。 還要注意的另一件事是，對于200萬個(gè)對象，Property Accessors接口僅不到14毫秒！ 正如我們將在第2部分稍后將帶回專用實(shí)例變量作為字段所看到的那樣 ，Property Accessors界面將真正隨著內(nèi)存使用而發(fā)光。

測試：對象使用屬性字段

以下是對象的所有字段都使用JavaFX屬性時(shí)的結(jié)果。

使用JavaFX屬性的對象與標(biāo)準(zhǔn)（胖）對象相比，所有字段均作為Javafx屬性。 此實(shí)現(xiàn)對每個(gè)字段使用數(shù)組索引，并使用數(shù)組保存每個(gè)值。

在這里，您會注意到200萬個(gè)對象的Accessor列（Property Accessors接口）在916毫秒內(nèi)執(zhí)行，使用了576 MB的內(nèi)存。 在這種情況下，就544 MB的內(nèi)存空間而言，標(biāo)準(zhǔn)（胖）對象是獲勝者。 到目前為止，Shadow Fields在每一輪比賽中都表現(xiàn)出色。

Marcel的代碼示例 （在注釋部分）的一個(gè)小細(xì)節(jié)是，在創(chuàng)建新的屬性對象實(shí)例時(shí)，它沒有考慮屬性的字符串名稱 。 例如，以下語句顯示變量totalProperty ，其屬性名為“ total ”，該屬性與totalProperty（）方法匹配。 在更改過程中觸發(fā)屬性名稱對于讀取代碼，測試和工具很重要。

屬性totalProperty = new SimpleIntegerProperty（this，“ total”，new Integer（5））;

為了同時(shí)擁有一個(gè)命名字段和一個(gè)類似于Marcel的想法的索引，我只創(chuàng)建了一個(gè)枚舉來聲明每個(gè)字段的屬性。 這些枚舉在Employee類上創(chuàng)建。

// Part 1 implementation public class EmployeePropertyAccessor implements PropertyAccessors{public enum FIELDS {name,powers,supervisor,minions}private final Object[] modelProperties =new Object[FIELDS.values().length];public Object[] getModelProperties(){return modelProperties;}// The rest of the code...

在上面，您會注意到將如何基于已定義字段（枚舉FIELDS）的數(shù)量創(chuàng)建模型Properties數(shù)組。 我使用FIELDS.value（）。length定義數(shù)組的大小。 另外， PropertyAccessors接口（ 第1部分的實(shí)現(xiàn) ）強(qiáng)制開發(fā)人員實(shí)現(xiàn)getModelProperties（）方法。 在這里，我只是返回對對象數(shù)組的modelProperties引用。 “ 必須 ”實(shí)現(xiàn)一個(gè)數(shù)組和一個(gè)getModelProperties（）方法并不是一件很愉快的事情 。

在本文的第2部分中，我以不同的方式實(shí)現(xiàn)了一些事情，其中??開發(fā)人員沒有被迫實(shí)現(xiàn)modelProperties數(shù)組和getModelProperties（）方法。 我將解決此問題，使代碼看起來更簡潔，性能更好（API觀點(diǎn)的用戶）。

第2部分：重新引入實(shí)例變量

在第2部分中，我將把私有實(shí)例變量重新添加到Employee類（ EmployeePropertyAccessor ）中，以保存字段值，而不是像第1部分中那樣包含數(shù)組。我的想法是使字段變量與指向本機(jī)對象的任一點(diǎn)互斥類型或JavaFX屬性，從而與“影子字段”模式代碼相比節(jié)省了內(nèi)存。 由于“ 陰影字段”代碼使用兩個(gè)變量來表示字段值，因此它將具有一個(gè)額外的引用，當(dāng)對象使用屬性時(shí)，該引用將不可避免地增加其內(nèi)存。 正如您在下面看到的那樣，該代碼看起來與第1部分相似，但也將具有一個(gè)靜態(tài)塊以在類中注冊屬性字段。 這很重要，因?yàn)槟赡懿幌Ｍ承?shí)例變量作為JavaFX屬性參與。

// Part 2 implementation public class EmployeePropertyAccessor implements PropertyAccessors {private Object name;private Object powers;private Object supervisor;private Object minions;enum FIELDS {name,powers,supervisor,minions}static {// register fields one time.// (Warning: enum's ordinal value is reassigned an index number)registerFields(EmployeePropertyAccessor.class, FIELDS.values());}public EmployeePropertyAccessor(String name, String powers) {setName(name);setPowers(powers);}public final String getName() {return getValue(FIELDS.name, "");}public final void setName(String name) {setValue(FIELDS.name, name);}public final StringProperty nameProperty() {return refProperty(FIELDS.name, SimpleStringProperty.class, String.class);}// The rest of the code...

上面的代碼清單在調(diào)用registerFields（）方法時(shí)做了一些有趣的魔術(shù) 。 使用反射重新分配 FIELDS枚舉的序數(shù)值，從而為每個(gè)枚舉賦予一個(gè)新的id作為數(shù)組的索引。 這提供了不可變的枚舉，同時(shí)還包含要通過索引快速訪問的每個(gè)字段的唯一標(biāo)識符。 由于枚舉用于表示要用作屬性的字段，因此序數(shù)值在其他上下文中沒有意義。 這意味著：誰在乎，是否在這些聲明的枚舉上重新分配了序數(shù)值？ 它們僅用于“ 注冊字段 ”。

測試：對象不使用屬性字段[NEW]

下面顯示的是使用Property Accessors接口API的新實(shí)現(xiàn)的測試結(jié)果。 下面的測試顯示了與標(biāo)準(zhǔn)胖對象相比，何時(shí)不使用屬性字段。

將標(biāo)準(zhǔn)對象（使用屬性的所有字段）與使用本機(jī)對象的對象進(jìn)行比較的測試。 現(xiàn)在，Property Accessors接口API使用實(shí)例變量作為字段，而不是對數(shù)組的引用。

正如您在上面看到的那樣，Property Accessors接口的新實(shí)現(xiàn)顯然是內(nèi)存使用率和易用性的贏家。 性能比第1部分的實(shí)現(xiàn)稍慢，但是節(jié)省內(nèi)存是值得的。 您會注意到，“影子字段”的內(nèi)存使用量比“屬性訪問器”的使用量多16 MB。

測試：對象使用屬性字段[NEW]

下面顯示的是使用Property Accessors接口API的新實(shí)現(xiàn)的測試結(jié)果。 下面的測試顯示與標(biāo)準(zhǔn)脂肪對象相比，何時(shí)使用屬性字段。 （在“開始”按鈕下方選中了該復(fù)選框）

第三回合的結(jié)果

以下是我根據(jù)表格中的結(jié)果匯總在一起的條形圖。 我覺得人們喜歡看圖表而不是表格，單元格和文本。

對象不使用JavaFX屬性時(shí)的性能測試結(jié)果。 較小的數(shù)字（以毫秒為單位）更好。

對象使用JavaFX屬性時(shí)的性能測試結(jié)果。 較小的數(shù)字（以毫秒為單位）更好。

對象不使用JavaFX屬性時(shí)的內(nèi)存使用情況測試結(jié)果。 較小的數(shù)字（以兆字節(jié)為單位）更好。

對象使用JavaFX屬性時(shí)的內(nèi)存使用情況測試結(jié)果。 較小的數(shù)字（以兆字節(jié)為單位）更好。

結(jié)論

根據(jù)結(jié)果??，我的目標(biāo)是明確實(shí)現(xiàn)的 （IMHO），我最初希望代碼在對象可能使用或不使用JavaFX屬性時(shí)都易于閱讀并且易于實(shí)現(xiàn)（ 當(dāng)字段不使用JavaFX時(shí)還可以節(jié)省內(nèi)存）屬性[本機(jī)類型] ）。 盡管在所有測試運(yùn)行中都贏得了性能方面的Shadow Fields的認(rèn)可，但Property Accessors界面并沒有落后。 當(dāng)不使用屬性時(shí)，在創(chuàng)建200萬條記錄時(shí)，Property Accessors界面僅比標(biāo)準(zhǔn)對象策略短5毫秒。

對于創(chuàng)建200萬個(gè)對象的內(nèi)存使用情況，以及當(dāng)策略未使用屬性作為字段時(shí)， Property Accessors界面顯然是贏家，與Shadow Fields模式相比至少節(jié)省16MB ，與Shadow Fields模式相比節(jié)省240MB。標(biāo)準(zhǔn)屬性代碼。 最后，但并非最不重要的是，當(dāng)對象將屬性用作字段時(shí)，Property Accessors接口與有關(guān)內(nèi)存消耗的Standard對象策略相關(guān)聯(lián)。 Shadow Fields策略使用的內(nèi)存至少比其他策略多20MB。

盡管在使用或不使用所有字段作為200萬個(gè)對象的屬性時(shí)，Properties Accessors接口會稍慢一些（以毫秒為單位的微小差異），但我相信該API可以在任何JavaFX應(yīng)用程序大小上使用，以簡化域的開發(fā)模型和對象。 我鼓勵(lì)其他人在決定使用API??之前先測試代碼。 請注意，該代碼不適合生產(chǎn)，并且處于試驗(yàn)階段。 這是一項(xiàng)正在進(jìn)行中的工作，因此，在我開始吃自己的狗食（工作時(shí)）之前，我真的不建議您使用Property Accessors API。 我將在下面重申免責(zé)聲明：

• 免責(zé)聲明：使用任何代碼均需自擔(dān)風(fēng)險(xiǎn)。 這純粹是實(shí)驗(yàn)性的，不應(yīng)在生產(chǎn)中使用。 這是一個(gè)進(jìn)展中的工作。

隨時(shí)發(fā)表評論和訂閱。 祝您編程愉快！

翻譯自: https://www.javacodegeeks.com/2016/04/shadow-fields-vs-property-accessors-interface-round-3.html

總結(jié)

以上是生活随笔為你收集整理的第三场阴影场与属性访问器接口的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。