作者：小傅哥
博客：https://bugstack.cn
沉澱、分享、成長，讓自己和他人都能有所收穫！
一、前言
程序員的上下文是什麼？
很多時候一大部分編程開發的人員都只是關注於功能的實現，只要自己把這部分需求寫完就可以了，有點像被動的交作業。這樣的問題一方面是由於很多新人還不了解程序員的職業發展，還有一部分是對於編程開發只是工作並非興趣。但在程序員的發展來看，如果不能很好的處理上文(產品)，下文(測試)，在這樣不能很好的了解業務和產品發展，也不能編寫出很有體繫結構的代碼，日久天長，1到3年、3到5年，就很難跨越一個個技術成長的分水嶺。
擁有接受和學習新知識的能力
你是否有感受過小時候在什麼都還不會的時候接受知識的能力很強，但隨着我們開始長大后，慢慢學習能力、處事方式、性格品行，往往會固定。一方面是形成了各自的性格特徵，一方面是圈子已經固定。但也正因為這樣的故步，而很少願意聽取別人的意見，就像即使看到了一整片內容，在視覺盲區下也會過掉到80%，就在眼前也看不見，也因此導致了能力不再有較大的提升。
編程能力怎樣會成長的最快
工作內容往往有些像在工廠擰螺絲，大部分內容是重複的，也可以想象過去的一年你有過多少創新和學習了新的技能。那麼這時候一般為了多學些內容會買一些技術書籍，但！技術類書籍和其他書籍不同，只要不去用看了也就只是輕描淡寫，很難接納和理解。就像設計模式，雖然可能看了幾遍，但是在實際編碼中仍然很少會用，大部分原因還是沒有認認真真的跟着實操。事必躬親才是學習編程的最好是方式。
二、開發環境
- JDK 1.8
- Idea + Maven
- 涉及工程三個，可以通過關注公眾號：
bugstack蟲洞棧，回復源碼下載獲取(打開獲取的鏈接，找到序號18)
| 工程 | 描述 |
|---|---|
| itstack-demo-design-11-01 | 使用一坨代碼實現業務需求 |
| itstack-demo-design-11-02 | 通過設計模式優化代碼結構，減少內存使用和查詢耗時 |
三、享元模式介紹
享元模式，主要在於共享通用對象，減少內存的使用，提升系統的訪問效率。而這部分共享對象通常比較耗費內存或者需要查詢大量接口或者使用數據庫資源，因此統一抽離作為共享對象使用。
另外享元模式可以分為在服務端和客戶端，一般互聯網H5和Web場景下大部分數據都需要服務端進行處理，比如數據庫連接池的使用、多線程線程池的使用，除了這些功能外，還有些需要服務端進行包裝后的處理下發給客戶端，因為服務端需要做享元處理。但在一些遊戲場景下，很多都是客戶端需要進行渲染地圖效果，比如；樹木、花草、魚蟲，通過設置不同元素描述使用享元公用對象，減少內存的佔用，讓客戶端的遊戲更加流暢。
在享元模型的實現中需要使用到享元工廠來進行管理這部分獨立的對象和共享的對象，避免出現線程安全的問題。
四、案例場景模擬
在這個案例中我們模擬在商品秒殺場景下使用享元模式查詢優化
你是否經歷過一個商品下單的項目從最初的日均十幾單到一個月後每個時段秒殺量破十萬的項目。一般在最初如果沒有經驗的情況下可能會使用數據庫行級鎖的方式下保證商品庫存的扣減操作，但是隨着業務的快速發展秒殺的用戶越來越多，這個時候數據庫已經扛不住了，一般都會使用redis的分佈式鎖來控制商品庫存。
同時在查詢的時候也不需要每一次對不同的活動查詢都從庫中獲取，因為這裏除了庫存以外其他的活動商品信息都是固定不變的，以此這裏一般大家會緩存到內存中。
這裏我們模擬使用享元模式工廠結構，提供活動商品的查詢。活動商品相當於不變的信息，而庫存部分屬於變化的信息。
五、用一坨坨代碼實現
邏輯很簡單，就怕你寫亂。一片片的固定內容和變化內容的查詢組合，CV的哪裡都是！
其實這部分邏輯的查詢在一般情況很多程序員都是先查詢固定信息，在使用過濾的或者添加if判斷的方式補充變化的信息，也就是庫存。這樣寫最開始並不會看出來有什麼問題，但隨着方法邏輯的增加，後面就越來越多重複的代碼。
1. 工程結構
itstack-demo-design-11-01
└── src
└── main
└── java
└── org.itstack.demo.design
└── ActivityController.java
- 以上工程結構比較簡單，之後一個控制類用於查詢活動信息。
2. 代碼實現
/**
* 博客：https://bugstack.cn - 沉澱、分享、成長，讓自己和他人都能有所收穫！
* 公眾號：bugstack蟲洞棧
* Create by 小傅哥(fustack) @2020
*/
public class ActivityController {
public Activity queryActivityInfo(Long id) {
// 模擬從實際業務應用從接口中獲取活動信息
Activity activity = new Activity();
activity.setId(10001L);
activity.setName("圖書嗨樂");
activity.setDesc("圖書優惠券分享激勵分享活動第二期");
activity.setStartTime(new Date());
activity.setStopTime(new Date());
activity.setStock(new Stock(1000,1));
return activity;
}
}
- 這裏模擬的是從接口中查詢活動信息，基本也就是從數據庫中獲取所有的商品信息和庫存。有點像最開始寫的商品銷售系統，數據庫就可以抗住購物量。
- 當後續因為業務的發展需要擴展代碼將庫存部分交給redis處理，那麼久需要從redis中獲取活動的庫存，而不是從庫中，否則將造成數據不統一的問題。
六、享元模式重構代碼
接下來使用享元模式來進行代碼優化，也算是一次很小的重構。
享元模式一般情況下使用此結構在平時的開發中並不太多，除了一些線程池、數據庫連接池外，再就是遊戲場景下的場景渲染。另外這個設計的模式思想是減少內存的使用提升效率，與我們之前使用的原型模式通過克隆對象的方式生成複雜對象，減少rpc的調用，都是此類思想。
1. 工程結構
itstack-demo-design-11-02
└── src
├── main
│ └── java
│ └── org.itstack.demo.design
│ ├── util
│ │ └── RedisUtils.java
│ ├── Activity.java
│ ├── ActivityController.java
│ ├── ActivityFactory.java
│ └── Stock.java
└── test
└── java
└── org.itstack.demo.test
└── ApiTest.java
享元模式模型結構
- 以上是我們模擬查詢活動場景的類圖結構，左側構建的是享元工廠，提供固定活動數據的查詢，右側是Redis存放的庫存數據。
- 最終交給活動控制類來處理查詢操作，並提供活動的所有信息和庫存。因為庫存是變化的，所以我們模擬的
RedisUtils中設置了定時任務使用庫存。
2. 代碼實現
2.1 活動信息
public class Activity {
private Long id; // 活動ID
private String name; // 活動名稱
private String desc; // 活動描述
private Date startTime; // 開始時間
private Date stopTime; // 結束時間
private Stock stock; // 活動庫存
// ...get/set
}
- 這裏的對象類比較簡單，只是一個活動的基礎信息；id、名稱、描述、時間和庫存。
2.2 庫存信息
public class Stock {
private int total; // 庫存總量
private int used; // 庫存已用
// ...get/set
}
- 這裡是庫存數據我們單獨提供了一個類進行保存數據。
2.3 享元工廠
public class ActivityFactory {
static Map<Long, Activity> activityMap = new HashMap<Long, Activity>();
public static Activity getActivity(Long id) {
Activity activity = activityMap.get(id);
if (null == activity) {
// 模擬從實際業務應用從接口中獲取活動信息
activity = new Activity();
activity.setId(10001L);
activity.setName("圖書嗨樂");
activity.setDesc("圖書優惠券分享激勵分享活動第二期");
activity.setStartTime(new Date());
activity.setStopTime(new Date());
activityMap.put(id, activity);
}
return activity;
}
}
- 這裏提供的是一個享元工廠，通過
map結構存放已經從庫表或者接口中查詢到的數據，存放到內存中，用於下次可以直接獲取。 - 這樣的結構一般在我們的編程開發中還是比較常見的，當然也有些時候為了分佈式的獲取，會把數據存放到redis中，可以按需選擇。
2.4 模擬Redis類
public class RedisUtils {
private ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(1);
private AtomicInteger stock = new AtomicInteger(0);
public RedisUtils() {
scheduledExecutorService.scheduleAtFixedRate(() -> {
// 模擬庫存消耗
stock.addAndGet(1);
}, 0, 100000, TimeUnit.MICROSECONDS);
}
public int getStockUsed() {
return stock.get();
}
}
- 這裏處理模擬
redis的操作工具類外，還提供了一個定時任務用於模擬庫存的使用，這樣方面我們在測試的時候可以觀察到庫存的變化。
2.4 活動控制類
public class ActivityController {
private RedisUtils redisUtils = new RedisUtils();
public Activity queryActivityInfo(Long id) {
Activity activity = ActivityFactory.getActivity(id);
// 模擬從Redis中獲取庫存變化信息
Stock stock = new Stock(1000, redisUtils.getStockUsed());
activity.setStock(stock);
return activity;
}
}
- 在活動控制類中使用了享元工廠獲取活動信息，查詢后將庫存信息在補充上。因為庫存信息是變化的，而活動信息是固定不變的。
- 最終通過統一的控制類就可以把完整包裝后的活動信息返回給調用方。
3. 測試驗證
3.1 編寫測試類
public class ApiTest {
private Logger logger = LoggerFactory.getLogger(ApiTest.class);
private ActivityController activityController = new ActivityController();
@Test
public void test_queryActivityInfo() throws InterruptedException {
for (int idx = 0; idx < 10; idx++) {
Long req = 10001L;
Activity activity = activityController.queryActivityInfo(req);
logger.info("測試結果：{} {}", req, JSON.toJSONString(activity));
Thread.sleep(1200);
}
}
}
- 這裏我們通過活動查詢控制類，在
for循環的操作下查詢了十次活動信息，同時為了保證庫存定時任務的變化，加了睡眠操作，實際的開發中不會有這樣的睡眠。
3.2 測試結果
22:35:20.285 [main] INFO org.i..t.ApiTest - 測試結果：10001 {"desc":"圖書優惠券分享激勵分享活動第二期","id":10001,"name":"圖書嗨樂","startTime":1592130919931,"stock":{"total":1000,"used":1},"stopTime":1592130919931}
22:35:21.634 [main] INFO org.i..t.ApiTest - 測試結果：10001 {"desc":"圖書優惠券分享激勵分享活動第二期","id":10001,"name":"圖書嗨樂","startTime":1592130919931,"stock":{"total":1000,"used":18},"stopTime":1592130919931}
22:35:22.838 [main] INFO org.i..t.ApiTest - 測試結果：10001 {"desc":"圖書優惠券分享激勵分享活動第二期","id":10001,"name":"圖書嗨樂","startTime":1592130919931,"stock":{"total":1000,"used":30},"stopTime":1592130919931}
22:35:24.042 [main] INFO org.i..t.ApiTest - 測試結果：10001 {"desc":"圖書優惠券分享激勵分享活動第二期","id":10001,"name":"圖書嗨樂","startTime":1592130919931,"stock":{"total":1000,"used":42},"stopTime":1592130919931}
22:35:25.246 [main] INFO org.i..t.ApiTest - 測試結果：10001 {"desc":"圖書優惠券分享激勵分享活動第二期","id":10001,"name":"圖書嗨樂","startTime":1592130919931,"stock":{"total":1000,"used":54},"stopTime":1592130919931}
22:35:26.452 [main] INFO org.i..t.ApiTest - 測試結果：10001 {"desc":"圖書優惠券分享激勵分享活動第二期","id":10001,"name":"圖書嗨樂","startTime":1592130919931,"stock":{"total":1000,"used":66},"stopTime":1592130919931}
22:35:27.655 [main] INFO org.i..t.ApiTest - 測試結果：10001 {"desc":"圖書優惠券分享激勵分享活動第二期","id":10001,"name":"圖書嗨樂","startTime":1592130919931,"stock":{"total":1000,"used":78},"stopTime":1592130919931}
22:35:28.859 [main] INFO org.i..t.ApiTest - 測試結果：10001 {"desc":"圖書優惠券分享激勵分享活動第二期","id":10001,"name":"圖書嗨樂","startTime":1592130919931,"stock":{"total":1000,"used":90},"stopTime":1592130919931}
22:35:30.063 [main] INFO org.i..t.ApiTest - 測試結果：10001 {"desc":"圖書優惠券分享激勵分享活動第二期","id":10001,"name":"圖書嗨樂","startTime":1592130919931,"stock":{"total":1000,"used":102},"stopTime":1592130919931}
22:35:31.268 [main] INFO org.i..t.ApiTest - 測試結果：10001 {"desc":"圖書優惠券分享激勵分享活動第二期","id":10001,"name":"圖書嗨樂","startTime":1592130919931,"stock":{"total":1000,"used":114},"stopTime":1592130919931}
Process finished with exit code 0
- 可以仔細看下
stock部分的庫存是一直在變化的，其他部分是活動信息，是固定的，所以我們使用享元模式來將這樣的結構進行拆分。
七、總結
- 關於享元模式的設計可以着重學習享元工廠的設計，在一些有大量重複對象可復用的場景下，使用此場景在服務端減少接口的調用，在客戶端減少內存的佔用。是這個設計模式的主要應用方式。
- 另外通過
map結構的使用方式也可以看到，使用一個固定id來存放和獲取對象，是非常關鍵的點。而且不只是在享元模式中使用，一些其他工廠模式、適配器模式、組合模式中都可以通過map結構存放服務供外部獲取，減少ifelse的判斷使用。 - 當然除了這種設計的減少內存的使用優點外，也有它帶來的缺點，在一些複雜的業務處理場景，很不容易區分出內部和外部狀態，就像我們活動信息部分與庫存變化部分。如果不能很好的拆分，就會把享元工廠設計的非常混亂，難以維護。
八、推薦閱讀
- 1. 重學 Java 設計模式：實戰工廠方法模式(多種類型商品發獎場景)
- 2. 重學 Java 設計模式：實戰抽象工廠模式(替換Redis雙集群升級場景)
- 3. 重學 Java 設計模式：實戰建造者模式(裝修物料組合套餐選配場景)
- 4. 重學 Java 設計模式：實戰原型模式(多套試每人題目和答案亂序場景)
- 5. 重學 Java 設計模式：實戰橋接模式(多支付渠道「微信、支付寶」與多支付模式「刷臉、指紋」場景)
- 6. 重學 Java 設計模式：實戰組合模式(營銷差異化人群發券，決策樹引擎搭建場景)
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※教你寫出一流的銷售文案?
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※回頭車貨運收費標準
※別再煩惱如何寫文案,掌握八大原則!
※超省錢租車方案
※產品缺大量曝光嗎?你需要的是一流包裝設計!