IOptions、IOptionsMonitor以及IOptionsSnapshot
背景
ASP.NET Core引入了Options模式，使用類來表示相關(guān)的設(shè)置組。簡單的來說，就是用強(qiáng)類型的類來表達(dá)配置項(xiàng)，這帶來了很多好處。
初學(xué)者會(huì)發(fā)現(xiàn)這個(gè)框架有3個(gè)主要的面向消費(fèi)者的接口：IOptions<TOptions>、IOptionsMonitor<TOptions>以及IOptionsSnapshot<TOptions>。
這三個(gè)接口初看起來很類似，所以很容易引起困惑，什么場景下該用哪個(gè)接口呢？
示例
我們先從一小段代碼著手（TestOptions類只有一個(gè)字符串屬性Name，代碼略）：
1 class Program 2 { 3 static void Main(string[] args) 4 { 5 var builder = new ConfigurationBuilder(); 6 builder.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true); //注意最后一個(gè)參數(shù)值，true表示配置文件更改時(shí)會(huì)重新加載。 7 var configuration = builder.Build(); 8 var services = new ServiceCollection(); 9 services.AddOptions(); 10 services.Configure<TestOptions>(configuration); //這里通過配置文件綁定TestOptions 11 var provider = services.BuildServiceProvider(); 12 Console.WriteLine("修改前："); 13 Print(provider); 14 15 Change(provider); //使用代碼修改Options值。 16 Console.WriteLine("使用代碼修改后："); 17 Print(provider); 18 19 Console.WriteLine("請(qǐng)修改配置文件。"); 20 Console.ReadLine(); //等待手動(dòng)修改appsettings.json配置文件。 21 Console.WriteLine("修改appsettings.json文件后："); 22 Print(provider); 23 } 24 25 static void Print(IServiceProvider provider) 26 { 27 using(var scope = provider.CreateScope()) 28 { 29 var sp = scope.ServiceProvider; 30 var options1 = sp.GetRequiredService<IOptions<TestOptions>>(); 31 var options2 = sp.GetRequiredService<IOptionsMonitor<TestOptions>>(); 32 var options3 = sp.GetRequiredService<IOptionsSnapshot<TestOptions>>(); 33 Console.WriteLine("IOptions值: {0}", options1.Value.Name); 34 Console.WriteLine("IOptionsMonitor值: {0}", options2.CurrentValue.Name); 35 Console.WriteLine("IOptionsSnapshot值: {0}", options3.Value.Name); 36 Console.WriteLine(); 37 } 38 } 39 40 static void Change(IServiceProvider provider) 41 { 42 using(var scope = provider.CreateScope()) 43 { 44 var sp = scope.ServiceProvider; 45 sp.GetRequiredService<IOptions<TestOptions>>().Value.Name = "IOptions Test 1"; 46 sp.GetRequiredService<IOptionsMonitor<TestOptions>>().CurrentValue.Name = "IOptionsMonitor Test 1"; 47 sp.GetRequiredService<IOptionsSnapshot<TestOptions>>().Value.Name = "IOptionsSnapshot Test 1"; 48 } 49 } 50 }
appsettings.json文件：
{ "Name": "Test 0" }
上面的代碼，首先從appsettings.json文件讀取配置，然后向容器注冊(cè)依賴配置文件的TestOptions，接著分別打印IOptions<>,IOptionsMonitor<>和IOptionsSnapshot<>的值。
接著通過代碼來修改TestOptions的值，打印。
然后通過修改appsettings.json文件來修改TestOptions的值，打印。
注意，我們僅注冊(cè)了一次TestOptions，卻可以分別通過IOptions<>,IOptionsMonitor<>和IOptionsSnapshot<>接口來獲取TestOptions的值。
如果我們把a(bǔ)ppsettings.json文件中Name的值修改為Test 2，那么上面這段代碼的輸出是這樣的：
分析
我們可以看到第一次通過代碼修改IOptions<>和IOptionsMonitor<>的值后，再次打印都被更新了，但是IOptionsSnapshot<>沒有，為什么呢？
讓我們從Options框架的源代碼著手，理解為什么會(huì)這樣。
當(dāng)我們需要使用Options模式時(shí)，我們都會(huì)調(diào)用定義在OptionsServiceCollectionExtensions類上的擴(kuò)展方法AddOptions(this IServiceCollection services)。
var services = new ServiceCollection(); services.AddOptions();
我們觀察AddOptions方法的實(shí)現(xiàn)：
public static IServiceCollection AddOptions(this IServiceCollection services) { if (services == null) { throw new ArgumentNullException(nameof(services)); } services.TryAdd(ServiceDescriptor.Singleton(typeof(IOptions<>), typeof(OptionsManager<>))); services.TryAdd(ServiceDescriptor.Scoped(typeof(IOptionsSnapshot<>), typeof(OptionsManager<>))); services.TryAdd(ServiceDescriptor.Singleton(typeof(IOptionsMonitor<>), typeof(OptionsMonitor<>))); services.TryAdd(ServiceDescriptor.Transient(typeof(IOptionsFactory<>), typeof(OptionsFactory<>))); services.TryAdd(ServiceDescriptor.Singleton(typeof(IOptionsMonitorCache<>), typeof(OptionsCache<>))); return services; }
從上面的代碼我們可以得知，IOptions<>和IOptionsMonitor<>被注冊(cè)為單例服務(wù)，而IOptionsSnapshot<>被注冊(cè)為范圍服務(wù)。
由于IOptions<>和IOptionsMonitor<>都被注冊(cè)為單例服務(wù)，因此每次獲取的都是同一個(gè)實(shí)例，所以更改了以后的值是保留的。
而IOptionsSnapshot<>被注冊(cè)為范圍服務(wù)，所以每次創(chuàng)建新范圍時(shí)獲取的都是一個(gè)新的值，外部的更改只對(duì)當(dāng)次有效，不會(huì)保留到下次（不能跨范圍，對(duì)于ASP.NET Core來說不能跨請(qǐng)求）。
我們繼續(xù)看第二次修改，第二次修改配置文件后IOptionsMonitor<>和IOptionsSnapshot<>的值更新了，而IOptions<>的值沒有更新。
IOptions<>好理解，它被注冊(cè)為單例服務(wù)，第一次訪問的時(shí)候生成實(shí)例并加載配置文件中的值，此后再也不會(huì)讀取配置文件，所以它的值不會(huì)更新。
IOptionsSnapshot<>被注冊(cè)為范圍服務(wù)，每次重新生成一個(gè)新的范圍時(shí)，它都會(huì)從配置文件中獲取值，因此它的值會(huì)更新。
但是，IOptionsMonitor<>呢，它被注冊(cè)為單例，為什么也會(huì)更新呢？
讓我們回到AddOptions的源代碼，我們留意到IOptionsMonitor<>的實(shí)現(xiàn)是OptionsManager<>。
當(dāng)我們打開OptionsManager的源代碼時(shí)，一切都很清楚了。
它的構(gòu)造函數(shù)如下：
public OptionsMonitor(IOptionsFactory<TOptions> factory, IEnumerable<IOptionsChangeTokenSource<TOptions>> sources, IOptionsMonitorCache<TOptions> cache) { _factory = factory; _sources = sources; _cache = cache; foreach (var source in _sources) { var registration = ChangeToken.OnChange( () => source.GetChangeToken(), (name) => InvokeChanged(name), source.Name); _registrations.Add(registration); } }
原來OptionsMonitor的更新能力是從IOptionsChangeTokenSource<TOptions>而來，但是這個(gè)接口的實(shí)例又是誰呢？
我們回到最開始的代碼的第10行：
services.Configure<TestOptions>(configuration);
這是一個(gè)定義在Microsoft.Extensions.Options.ConfigurationExtensions.dll的擴(kuò)展方法，最后實(shí)際調(diào)用的是它的一個(gè)重載方法，代碼如下：
1 public static IServiceCollection Configure<TOptions>(this IServiceCollection services, string name, IConfiguration config, Action<BinderOptions> configureBinder) 2 where TOptions : class 3 { 4 if (services == null) 5 { 6 throw new ArgumentNullException(nameof(services)); 7 } 8 9 if (config == null) 10 { 11 throw new ArgumentNullException(nameof(config)); 12 } 13 14 services.AddOptions(); 15 services.AddSingleton<IOptionsChangeTokenSource<TOptions>>(new ConfigurationChangeTokenSource<TOptions>(name, config)); 16 return services.AddSingleton<IConfigureOptions<TOptions>>(new NamedConfigureFromConfigurationOptions<TOptions>(name, config, configureBinder)); 17 }
秘密就在上面的第15行，ConfigurationChangeTokenSource，它引用了代表配置文件的對(duì)象config，所以配置文件更新，IOptionsMonitor就會(huì)跟著更新。
結(jié)論
IOptions<>是單例，因此一旦生成了，除非通過代碼的方式更改，它的值是不會(huì)更新的。
IOptionsMonitor<>也是單例，但是它通過IOptionsChangeTokenSource<> 能夠和配置文件一起更新，也能通過代碼的方式更改值。
IOptionsSnapshot<>是范圍，所以在配置文件更新的下一次訪問，它的值會(huì)更新，但是它不能跨范圍通過代碼的方式更改值，只能在當(dāng)前范圍（請(qǐng)求）內(nèi)有效。
官方文檔是這樣介紹的：
IOptionsMonitor<TOptions>用于檢索選項(xiàng)和管理TOptions實(shí)例的選項(xiàng)通知，它支持下面的場景：
- 實(shí)例更新通知。
- 命名實(shí)例。
- 重新加載配置。
- 選擇性的讓實(shí)例失效。
IOptionsSnapshot<TOptions>在需要對(duì)每個(gè)請(qǐng)求重新計(jì)算選項(xiàng)的場景中非常有用。
IOptions<TOptions>可以用來支持Options模式，但是它不支持前面兩者所支持的場景，如果你不需要支持上面的場景，你可以繼續(xù)使用IOptions<TOptions>。
所以你應(yīng)該根據(jù)你的實(shí)際使用場景來選擇到底是用這三者中的哪一個(gè)。
一般來說，如果你依賴配置文件，那么首先考慮IOptionsMonitor<>，如果不合適接著考慮IOptionsSnapshot<>，最后考慮IOptions<>。
有一點(diǎn)需要注意，在ASP.NET Core應(yīng)用中IOptionsMonitor可能會(huì)導(dǎo)致同一個(gè)請(qǐng)求中選項(xiàng)的值不一致——當(dāng)你正在修改配置文件的時(shí)候——這可能會(huì)引發(fā)一些奇怪的bug。
如果這個(gè)對(duì)你很重要，請(qǐng)使用IOptionsSnapshot，它可以保證同一個(gè)請(qǐng)求中的一致性，但是它可能會(huì)帶來輕微的性能上的損失。
如果你是在app啟動(dòng)的時(shí)候自己構(gòu)造Options（比如在Startup類中）：
services.Configure<TestOptions>(opt => opt.Name = "Test 0");
IOptions<>最簡單，也許是一個(gè)不錯(cuò)的選擇，Configure擴(kuò)展方法還有其他重載可以滿足你的更多需求。
浙公網(wǎng)安備 33010602011771號(hào)