2024年8月12日 星期一

[.Net/Memory] managed heap裡的Class+<>c是什麼?

 前言:

有一次在記憶體snapshot中發現某個ClassName+<>c的物件,如下圖紅框處:


第一次看到有點不知所以,查了一下,這是compiler建立用來執行lambda的class。

To be continued...



參考資料:

https://blog.jetbrains.com/dotnet/2019/01/23/c-classes-memory-snapshots/

2023年8月9日 星期三

[C#] 沒有取消訂閱(unsubscribe)事件(event)會導致memory leak?

 Publisher物件可提供事件供其他subscriber物件做訂閱,且一般也會在適當的時機點取消訂閱,

但如果只訂閱但沒有取消訂閱,會讓程式memory leak嗎?


我將情境分為以下4種:

1. Publisher生命週期較subscriber長,subscriber有取消訂閱。

2. Publisher生命週期較subscriber長,subscriber沒有取消訂閱。

3. Publisher生命週期較subscriber短,subscriber有取消訂閱。

4. Publisher生命週期較subscriber短,subscriber沒有取消訂閱。


Publisher使用下圖的Server類別:

Subscriber使用下圖的Log類別,Log訂閱Server的ServerConnected事件:


以下依序列出測試結果,這裡使用VS內建的記憶體快照來確認物件是否已GC:

1. Publisher生命週期較subscriber長,subscriber有取消訂閱:

    可以看到Log物件(subscriber)已經被GC了。

2. Publisher生命週期較subscriber長,subscriber沒有取消訂閱:

    可以看到Log物件(subscriber)還存在記憶體。

3. Publisher生命週期較subscriber短,subscriber有取消訂閱:

4. Publisher生命週期較subscriber短,subscriber沒有取消訂閱:

情境3跟4,都是Server物件先回收,Log物件還留著的情形,記憶體快照也是一樣結果,
代表publisher先回收的話,subscriber沒有取消事件訂閱,也沒有關係:


結論是,subscriber還是要在適當時機點取消事件訂閱,如同情境2的結果,訂閱長生命週期的事件,是會造成memory leak的。

2023年4月16日 星期日

[UML] UML的關聯(association)、依賴(dependency)與差異

 關聯(association)與依賴(dependency)是UML類別圖常用來描述類別間的關係。

 關聯的表示如下,Customer關聯Order,用實線指到目標類別:


依賴的表示如下,MessageBroker依賴MessageFormat,虛線表示:









會覺得好像有點像? 

關聯是用在A類別擁有B類別的執行個體參考,如下程式碼:


而依賴則是代表A類別在其方法內建立或使用B類別的instance,
也就是A類別並沒有保存B類別的物件。








而箭頭上的數字就代表擁有參考的數量,如下圖就代表Customer擁有多張Order。


其實關聯還有其他2個特殊形式,聚合(aggregation)與組合(composition),
不過直接用關聯表示也可以,除非真的需要特別呈現出來。


2022年12月25日 星期日

[C#] 讓event handler method不因event多次觸發而重複執行

 前言:

最近遇到一個情境,物件的某個event trigger會多次,

但訂閱的event handler method只需要處理該event trigger的第一次,

該怎麼做呢?


作法:

如下圖的Document類別,有一個Loaded事件,當呼叫Open方法時會觸發Loaded事件。


client端訂閱該Loaded事件,但只需要針對第一次觸發做處理,也就是讓event handler method只執行一次。因為event是把delegate清單wrap起來,
因此再加入第2個delegate將上一個event handler移除事件訂閱。

可以看到雖然Loaded事件觸發2次,但訂閱的event handler method只執行1次。


2021年10月31日 星期日

[SQL Server] 如何使用執行計畫(execution plan)判斷statement效能

 前言:

提到資料庫存取,大多會擔心撰寫的statement是否有效能問題,

雖然公司可能會有DBA來review開發人員的statement,

但開發人員仍需初步判斷所寫的statement執行的狀況。

以SQL Server來說,會使用SSMS(SQL Server Management Studio)裡的執行計畫(Execution plan)來判斷。


作法:

可以準備幾個要比較statement來跑執行計畫,一般會先看是否有吃到index,

效能通常是:index seek > index scan

但如果SELECT的資料筆數接近整張table的筆數,SQL Server就可能採table scan將資料回傳。


基本上使用PK來當條件,就會套用cluster index seek。cluster index預設是從table的PK建出來的,每張table只會有一組,如下圖OrderID是[Orders]的唯一PK。



還有一種是nonclustered index seek,nonclustered index在一張table可以有多組,可以視SELECT資料的需求來建立。如下圖CustomerID是[Orders]的其一nonclustered index。


至於index scan,可分為cluster index scan,如下圖。


另一種則是noncluster index scan。


to be continued...


參考資料:

https://docs.microsoft.com/zh-tw/sql/relational-databases/sql-server-index-design-guide?view=sql-server-ver15

https://docs.microsoft.com/zh-tw/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-described?view=sql-server-ver15

https://github.com/Microsoft/sql-server-samples/tree/master/samples/databases/northwind-pubs

2021年5月31日 星期一

[Design Pattern] 狀態模式(State Pattern)


前陣子開發電子化表單相關的程式,剛好使用到狀態模式(State Pattern)。

需求是每張表單有其狀態,每個狀態有對應的處理動作,

因此直覺上可以使用狀態模式的概念來處理。


先上個類別圖:



這邊使用抽象類別StateBase,下方的類別就是實際的狀態,

以請假表單來說,會有初始狀態與主管審核後狀態,

Execute方法代表執行狀態對應的動作,可能是狀態移轉或通知對應的人。

而StateContext是管理狀態的類別,其Request方法呼叫state物件的Execute方法,

並注入執行的state instance,以提供狀態執行所需的環境資訊。


剛好這需求,一開始同事是使用switch case來處理各狀態行為,

我改成狀態模式,避免全部的狀態行為都擠在同一個方法,

後續擴充維護也會容易許多,這也是Open–closed principle的精神。

2021年1月19日 星期二

[Web] OAuth Authorization code flow筆記與取得google userinfo範例

 

Authorization Code是OAuth的其中一種授權方式,

可以讓client程式取得使用者(resource owner)外部的資源,需要使用者輸入帳密,

流程如下:

● 觸發驗證流程後,client程式將使用者的瀏覽器導向authorization server的驗證端點(authorize endpoint)。

● 此時網頁會顯示client程式想存取使用者在外部的哪些資源,等待使用者授權。

● authorization server依使用者回應與帳密決定是否授權。

  • 若使用者允許,則authorization server會依client程式註冊OAuth服務時填寫的redirection URI,將authorization code導回給client程式。
  • 若使用者不允許或無法成功授權,則將錯誤訊息導回client程式。

● client程式再帶authorization code、redirection URI等參數POST到authorization server的權杖端點(token endpoint)。

● authorization server確認參數無誤後,即回傳access token相關資訊,即可以此token跟resource server要資料。


以Flow chart描述流程如下:



來個實際操作吧,這邊使用Google OAuth來取得userinfo:

  • 先到google developer console的Credentials頁面,新增OAuth client ID,至少要給redirect URIs,儲存後就會拿到ClientID與Secret。
  • 組合取得Authorization code的url,紅色部份依實際狀況填入:

https://accounts.google.com/o/oauth2/v2/auth?

client_id=client id from google oauth setting&

redirect_uri=redirect_uri from google oauth setting&

response_type=code&

scope=profile&

access_type=offline&

state=up to you

  • GET呼叫取得Authorization code的url,google server會callback Authorization code,code通常是4%2F開頭,要注意有url encode,所以要轉為4/。
  • 接著POST呼叫要token,code就帶Authorization code,通常超過10分鐘會失效,如下圖,即可取得欲存取資源的token。


  • 最後拿token即可存取授權的資源:



參考資料:

https://tools.ietf.org/html/rfc6749

https://developers.google.com/identity/protocols/oauth2/web-server