國外實測新款 Surface Pro X 的 SQ2 處理器效能幾乎跟 SQ1 一樣

微軟在去年十月時正式更新旗下 Surface Pro X 平版電腦,處理器升級至 SQ2,一樣是高通 ARM 架構,不過當時微軟並沒有特別說明這顆處理器的效能表現,而最近終於有外媒實測到實機,但讓人意外的是,跑分結果竟然跟 SQ1 差不多,也就是新款 Surface Pro X 效能幾乎沒有什麼提升。

新款 Surface Pro X 的 SQ2 處理器效能幾乎跟 SQ1 一樣

稍早一間德國媒體網站 Dr. Windows 分享 Surface Pro X 2020 年版的實測報告,共使用三款跑分軟體進行測試,並與舊款 Surface Pro X 比較,結果如下。

首先是 Jetstream 2 瀏覽器測試工具:

  • 搭載 SQ1 處理器的 Surface Pro X 2019 獲得 89,614
  • 搭載 SQ2 處理器的 Surface Pro X 2020 獲得 90,664

安兔兔測試工具:

  • 搭載 SQ1 處理器的 Surface Pro X 2019 獲得 286,740
  • 搭載 SQ2 處理器的 Surface Pro X 2020 獲得 286,271

Geekbench 4 測試工具:

  • 搭載 SQ1 處理器的 Surface Pro X 2019 單核心獲得 3,530、多核心獲得 11,927
  • 搭載 SQ2 處理器的 Surface Pro X 2020 單核心獲得 3,627、多核心獲得 12,042

三個測試結果中,Jetstream 2 與 Geekbench 4 雖然新款確實比較高,但也只有多一點點,安兔兔反而變低。整體來看,幾乎可以說搭載 SQ2 處理器的 Surface Pro X 2020 效能並沒有提升。

另外最近微軟官方的韌體更新中,也都合併支援 SQ1 與 SQ2 處理器:

不確定為何這兩顆效能會這麼接近,但也顯示著,對於注重效能的朋友來說,舊款 Surface Pro X 或許是 CP 值更高的選擇。

當然,除了效能,Surface Pro X 2020 還是有地方提升,像續航力官方就承諾可達到 15 小時,比舊款多 2 小時。

無論如何,有在關注新款 Surface Pro X 2020 的人,建議等更多實測報告現身再做決定。

資料來源:Dr. Windows

微軟最新的廣告,直白地跟你說 Surface Pro 7 就是比 MacBook Pro 好

您也許會喜歡:

【推爆】終身$0月租 打電話只要1元/分

立達合法徵信社-讓您安心的選擇

【其他文章推薦】

※回頭車貨運收費標準

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※推薦評價好的iphone維修中心

※教你寫出一流的銷售文案?

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

這幾款10萬級車型投訴率最低,最可靠!竟然沒有日系

吉利遠景指導價:5。39-6。79萬推薦車型:2017款1。5L自動幸福版10月份銷量:15721輛10月份投訴量:4單吉利汽車無論是轎車還是SUV,都對汽車銷量市場貢獻了不少的成績,SUV有博越,遠景SUV和帝豪GS,轎車則有博瑞,帝豪GL和今天介紹的這款遠景,在上個月賣出了1。

根據中國汽車工業協會提供的數據表示,在10月份全國轎車的銷售量達到了117.05萬輛,車主朋友們對轎車的有效投訴達到2538宗,在投訴案例中,大多數朋友投訴的內容為發動機功率不足,車內異味以及變速箱異響的問題。而今天想為大家介紹的這幾款,確實是經過了後市場的考驗,投訴量非常少的質量可靠性轎車,不妨參考參考。

雪佛蘭科沃茲

指導價:7.99-10.99萬

推薦車型:2016款 1.5L自動欣悅版

10月份銷量:13836輛

10月份投訴量:0

在科沃茲還沒正式亮相之前,就有不少的粉絲在後台問這款車如何,而該車推出至今已經有幾個月,論質量論實力,在10萬元代步家轎中,一直保持着不錯的成績,這次通過數據來看,在9月份10月份後市場依然還沒收到科沃茲車主的投訴,這其實就是一個很好的證明了。

科沃茲外觀採用雪佛蘭家族式的雙層前格柵,燈組內部有點綴鍍鉻飾條和全新的雙L形LED光帶式日間行車燈,全系標配,內飾採用傳統飛翼式座艙設計,同時座椅提供更加出色的側向支撐和包裹性。動力上全系採用1.5L自然吸氣發動機,搭配5速手動和6速手自一體變速器,推薦的這個自動欣悅版,標配胎壓監測,ESp車身穩定,上坡輔助,天窗以及發動機啟停裝置,應該有的配置沒有差。

全力加速時轉速爬升得比較慢,大約在2500轉左右,爆發力只能說一般般,不過在加速的時候降擋相當果斷,方向盤力度沉穩,平時在道路上做併線動作也蠻幹脆利索,但是整體的駕駛感受上還是比本田鋒范差點,百公里平均油耗7L。

東風悅達起亞K2

指導價: 7.29-10.39萬

推薦車型: 2017款 三廂 1.4L AT GLS

10月份銷量:16882

10月份投訴量:3

在網絡上曾傳聞着這樣一篇文章“十大最不安全車輛”,在這個由美國評定出來的車型當中,就屬起亞K2首當其沖,雖然在這個等級上舊款起亞K2由於自身問題慘入榜單,但是相信最近剛上市的全新2017款K2能夠帶給大家不一樣的感覺。

全新的起亞K2前臉變化很大,整個車頭設計都讓人煥然一新,虎嘯式格柵面積更小,側面也比舊款顯得更加修長,沒有那麼笨重,車尾則加入了貫穿式尾燈,識別程度非常之高。內飾風格也是全新設計,中控彩色屏幕支持蘋果Carplay和百度Carlife功能,還有倒車雷達和影像,這可能是最實用的功能了,其他像ESp車身穩定和胎壓監測上坡輔助等,都變成後期加裝了,選起亞K2,確實會面臨這個尷尬的問題。

動力上提供1.4L和1.6L兩種排量的自然吸氣發動機,傳統的4AT變速器遭捨棄,升級為6速手自一體和6速手動擋變速器,試駕感受上油門踏板初段有些遲緩,需要捨得給油地深踩才會感覺到動力的提升,懸架偏向於舒適,但過減速帶感覺還是比較明顯。

吉利遠景

指導價:5.39-6.79萬

推薦車型:2017款1.5L自動幸福版

10月份銷量:15721輛

10月份投訴量:4單

吉利汽車無論是轎車還是SUV,都對汽車銷量市場貢獻了不少的成績,SUV有博越,遠景SUV和帝豪GS,轎車則有博瑞,帝豪GL和今天介紹的這款遠景,在上個月賣出了1.5多萬輛的成績,只接到4單車主用戶的投訴,這個成績還是蠻可以的。

在外觀上,2017款對前臉進氣格柵造型做了小調整,統一了家族式風格的“回”字形造型,更加時尚,內飾設計變化不大,這次該款主要是配置升級了一點,配置雖然沒有ESp車身穩定(本田飛度大部分車型也沒有),但其他配置如后倒車雷達及影像,前後攝像頭,定速巡航等功能,在這款6.69萬的1.5L自動擋版本上看到,就已經非常奇迹了,感覺賺到了。

該車不僅配備1.5L自然吸氣,如果對動力需求更大可以入手1.3T渦輪增壓版本,不過該版本沒有匹配自動變速器,比較可惜,整體車內儲物空間還是蠻多的,這輛車,價格便宜是最大的賣點,且賣出去后,用戶投訴量也非常少,可以考慮。

大眾捷達

指導價:7.99-12.08萬

推薦車型:2015款 質惠版1.6L自動舒適型

10月份銷量:29637輛

10月份投訴量:6單

捷達車型相信大家都相當熟悉了,它在我國存在的年份已經相當之久,雖然很少在網上看到它的宣傳廣告,但它一直在我國的銷量都非常好,10月份總共賣出的車輛就直逼3萬大軍,收到的投訴量也只有6單,如果真要將這4台車型來列個投訴銷量比的話,無疑大眾捷達得到的分數是最高的。

2015款的外觀還是比較圓潤中庸,內飾風格還是那麼簡樸老成,大眾標準內飾設計風格,沒有多大可以描述的地方,針對捷達來說,有着多種發動機排量可以選擇,有着1.4L和1.6L的自然吸氣版本,同時也有1.4T渦輪增壓的大動力版本,根據不同排量的發動機,匹配5速手動,6速自動和7速雙離合變速器,配置上基本不標配ESp,大部分為選裝情況。

可能大家買捷達,就是衝著德系技術,且捷達車耐用好開的特性吧,配置其實並不是絕大多數人考慮的地方,品牌效應早已超過了其他,在試駕過程中深加速時發動機噪音大,底盤比較穩,質感不錯,如今2017款新捷達已經亮相,期待上市后的市場反應。

本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※推薦評價好的iphone維修中心

網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!

從“中英文思維回譯法”看中英思維差異

1、中英文在表達意思的方式上的不同 

中英文表達的差異很重要一部分體現在思維上。例如中文說:

“不知道怎麼回事,我筆記本連不上網了”

地道的英文不是:

My laptop can’t connect to the internet for no reason.

而是:

I couldn’t access the internet from my laptop for some reason.

這個句子至少體現了以下幾處中英文思維的不同:

  • 中文用“我的電腦”做主語,英語用“我”做主語。
  • “上網”是 access the internet 而不是 connect to the internet.
  • 不知道怎麼回事是 for some reason 而不是 for no reason.
  • 中文先說“不知道怎麼回事”,英文後說 for some reason.

 

2、中英文思維的差異

作為跨文化交流的翻譯不僅只是兩種語言的簡單轉換,也是兩種思維方式之間的轉換。 拿英漢兩種語言來說.由於文化背景的差異等諸多因素,這兩種語言的思維方式也不盡相同,概括來說主要就是:

  • 句子重心的差異
  • 語態的差異
  • 否定視角的差異

0x1:句子重心的差異

句子重心包括兩個層面:

  • 一個是語義重心
  • 另一個是結構重心

英語和漢語的語義重點基本沒有大的區別,這兩種語言句子重心的差異主要體現在結構重心的差異上。

西方人說話喜歡直截了當、開門見山,他們在表達思想時喜歡先安排主要內容,然後再藉助各種連接手段補充其他信息,因而英語句子的結構重心通常在前,句子常常頭短尾長。

而中國人則喜歡水到渠成、漸入佳境。所以他們在表達思想時喜歡先對所述的事物進行鋪墊和渲染,然後再點出中心意思,因而漢語句子的結構重心往往靠後,句子頭長尾短。

我們來看下面的例句:

我們再來看一個例句:

這句話的結構重心為後半句“許多小船載着各種雜貨快速向客輪駛來”。通過上面的分析,這句話在翻譯時應首先將結構重心置前,先說主要內容:

0x2:語態的差異

雖然英漢兩種語言在句式上都有主動和被動之分,但表現形式和使用場合卻不盡相同。

  • 英語中被動語態的使用範圍非常廣,除了大量的及物動詞使用被動語態外,不少相當於及物動詞的短語也可以使用被動語態。
  • 相比之下,漢語中被動語態的使用就低得多了,大多數情況下漢語都使用主動形式來表達被動意義。

以“He is loved by all of us.”這句話為例,這句話在英語中司空見慣,而如果要譯成“他被我們大家喜歡着”就很彆扭,必須要使用主動語態,譯成“我們大家都喜歡他”才通順。

我們來看下面的例句:

 

被動語態能使句子的核心詞“an interesting discovery”更為突出。

我們再來看一個例句:

中文原句是主動語態,但由於“開挖隧道”和“派狗到雪地里”這兩個動作的發出者在中文里並沒有出現,所以在譯成英語時就只能使用被動語態了。

中文中有大量的無主句,在將這些句子譯成英文時都可以使用被動語態。

0x3:否定視角的差異

英語的否定方式非常豐富,大體可分為:

  • 顯形否定:通常是藉助否定詞或,含否定意義的句型來表達(如never、unless、hardly、rather than、in the absence of、too …. to …)
  • 隱形否定:沒有明顯的否定詞,其形式上是否定的,它的否定含義要通過上下文或語境來推定

與英語比起來,漢語的否定結構就單一多了,一般是在相應的詞語前面加上“不”、“沒有”等進行“詞的否定”。

所以,在漢譯英的過程中,對於漢語中相對單一的否定結構,英文中可以有多種不同的表達方式。

我們來看下面的例句:

可以看到,譯文採用了隱形否定的形式來表達。

我們再來看一個例句:

 

中文原文是肯定句,而譯文中使用了否定結構“never fail to”不僅表達了肯定的意思,還顯得更為精彩,更有力量。

3、中英文回譯法

在翻譯練習中,有一種非常有效翻譯方法叫“回譯法”,也就是對譯文進行再次翻譯后與原文進行對照,在對比中找到差異所在。 概括來說就是:

  • 從地道英語直譯成中文
  • 由直譯的中文再譯成地道的中文
  • 仔細分析記錄地道英語和地道中文的區別
  • 由地道中文再回譯成地道英文

0x1:英譯中 – 從 A 到 B

我們先徹底理解英文原文的意思,然後嘗試着翻譯成中文。如果覺得直譯很彆扭的話,那就說明這裡有值得一學的英語思維! 在這一步,我們要做到讓中文譯文符合英文原文的表述,盡量直譯,基本通順即可。 舉個例子: 一位商務人士因為電腦有問題連不上網,沒能及時回復重要郵件,等修好了,他趕緊給別人發郵件解釋,郵件開頭是這麼說的:  

這句話直譯過來就是:

我很抱歉沒能更早回復你,出於某些原因,我用筆記本電腦無法連上網。

0x2:重建中文 – 從 B 到 C

這一步,我們要引入中文思維,展開想象:

在真實的中文語境中,相同的場景中,人們會怎麼說這句話?

這一步需要你完全拋棄英文原文的影響,去想中國人真正會使用出來的中文,不能有任何的翻譯痕迹。你可以假象在同樣的場景中,你自己會如何表達。例如:

不好意思啊,這麼晚回復你,我的本子一直連不上網,不知道怎麼回事。

到這一步我們發現,經過重建的中文,已經和之前的譯文在表達順序和結構上有明顯區別了。

0x3:連接通過 – 找到 A 和 C 之間的關聯

這一步也叫“埋鈎子”,就是說,埋下一些幫助記憶的“小鈎子”,把兩種思維掛上,讓自己以後能回想起來。

我們要觀察的內容主要是三方面:

  • 多了什麼?
  • 少了什麼?
  • 改了什麼?

比如:

  • 句子結構是怎麼變的?
  • 哪些詞被捨棄了?
  • 哪些表達式被徹底替換了?
  • 為什麼有些信息乾脆就不說了?
  • 有些信息反而要被加上去?

以這句話為例,我會注意到,

  • 我們中國人通常說的“這麼晚回復你”,英文的表達思路不一定用so late,還可以用not sooner,即否定句式。
  • 連上網,這句話里用的是access這個詞,而不是我們更熟悉的connect to。
  • 句子的主語也變了,一般中文會說“我的筆記本連不上網”,主語是筆記本,但是英文原文的說法是“i coudn’t access the internet”,主要是 I,也就是我。是我沒法通過本子來連網,而不是說本子連不上網。

0x4:思維逆轉 – 把 C 譯回 A

最後一步,我們要把整個過程逆推回去,在只看到 C 的情況下,回想起 A 是怎麼說的。如果你能做到準確完成回譯,說明你已經成功地建立了通道,從中文思維跳到了英文思維。

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計最專業,超強功能平台可客製化

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

※教你寫出一流的銷售文案?

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家公司費用怎麼算?

Spring 源碼學習 – 單例bean的實例化過程

本文作者:geek,一個聰明好學的同事

1. 簡介

開發中我們常用@Commpont,@Service,@Resource等註解或者配置xml去聲明一個類,使其成為spring容器中的bean,以下我將用從源碼角度看以AnnotationConfigApplicationContext為例看spring如何把帶有註解的類生成spring中bean。

2. 示例代碼

public class TestContext {
	public static void main(String[] args) {
		AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
		SingleBean singleBean = context.getBean(SingleBean.class);
		System.out.println("<=====>"+singleBean.getTestStr());
	}
}
@ComponentScan("com.geek")
public class AppConfig {
}
@Component
public class SingleBean {
	private String testStr = "testStr";

	public String getTestStr() {
		return testStr;
	}
}

注意:以上代碼僅需要引入spring-context依賴即可。

3. 源碼分析

​ 上面的demo在調用AnnotationConfigApplicationContext構造函數的時候,AppConfig類會被註冊到AnnotatedBeanDefinitionReader,由這個reader把AppConfig解釋為beanDefination,從而被spring獲取到要實例化的類信息,以下為bean生產的源碼及其註釋。(源碼基於springFramework 5.1.X)

3.1 創建入口

​ 單例bean的創建的入口為DefaultListableBeanFactory.java#preInstantiateSingletons,下面源碼可見創建的bean條件為非抽象,非@LazyInit註解,Scope為singleTon(默認為singleTon)。

@Override
	public void preInstantiateSingletons() throws BeansException {
		if (logger.isTraceEnabled()) {
			logger.trace("Pre-instantiating singletons in " + this);
		}
		// Iterate over a copy to allow for init methods which in turn register new bean definitions.
		// While this may not be part of the regular factory bootstrap, it does otherwise work fine.
		//所有可能需要去實例化的class(lazy,scope)
		List<String> beanNames = new ArrayList<>(this.beanDefinitionNames);

		// Trigger initialization of all non-lazy singleton beans...
		for (String beanName : beanNames) {
			RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
			/**
			 * 非抽象,非懶初始化,單例bean
			 */
			if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
				if (isFactoryBean(beanName)) {
					Object bean = getBean(FACTORY_BEAN_PREFIX + beanName);
					if (bean instanceof FactoryBean) {
						final FactoryBean<?> factory = (FactoryBean<?>) bean;
						boolean isEagerInit;
						if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) {
							isEagerInit = AccessController.doPrivileged((PrivilegedAction<Boolean>)
											((SmartFactoryBean<?>) factory)::isEagerInit,
									getAccessControlContext());
						}
						else {
							isEagerInit = (factory instanceof SmartFactoryBean &&
									((SmartFactoryBean<?>) factory).isEagerInit());
						}
						if (isEagerInit) {
							getBean(beanName);
						}
					}
				}
				//非工廠bean實例化
				else {
					getBean(beanName);
				}
			}
		}
		/**
		 * 實例化完成后觸發實現了SmartInitializingSingleton方法的bean
		 * 的afterSingletonsInstantiated方法
 		 */
		// Trigger post-initialization callback for all applicable beans...
		for (String beanName : beanNames) {
			Object singletonInstance = getSingleton(beanName);
			if (singletonInstance instanceof SmartInitializingSingleton) {
				final SmartInitializingSingleton smartSingleton = (SmartInitializingSingleton) singletonInstance;
				if (System.getSecurityManager() != null) {
					AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
						smartSingleton.afterSingletonsInstantiated();
						return null;
					}, getAccessControlContext());
				}
				else {
					smartSingleton.afterSingletonsInstantiated();
				}
			}
		}
	}

3.2 創建前doGetBean代碼邏輯

getBean方法進來后便是直接調用doGetBean,doGetBean執行的源碼解釋如下:
protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,
			@Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
		/**
		 * 獲取beanName
		 * 1,去掉factortoryBean前綴&
		 * 2,帶有別名的bean轉換為原來名字
		 */
		final String beanName = transformedBeanName(name);
		Object bean;
		// Eagerly check singleton cache for manually registered singletons.
		/**
		 * 從DefaultSingletonBeanRegistry的singletonObjects
		 * (spring內部用來緩存單例bean的currentHashMap)檢查是否存在該bean,不存在則創建
		 * 涉及單例模式下的循環依賴解決
		 */
		Object sharedInstance = getSingleton(beanName);
		if (sharedInstance != null && args == null) {
			if (logger.isTraceEnabled()) {
				if (isSingletonCurrentlyInCreation(beanName)) {
					logger.trace("Returning eagerly cached instance of singleton bean '" + beanName +
							"' that is not fully initialized yet - a consequence of a circular reference");
				}
				else {
					logger.trace("Returning cached instance of singleton bean '" + beanName + "'");
				}
			}
			/**
			 *獲取給定bean實例的對象,如果是Factory Bean,
			 * 則可以是bean實例本身或其創建的對象。
			 */
			bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
		}
		else {
			// Fail if we're already creating this bean instance:
			// We're assembly within a circular reference.
			/**
			 * 原型模式下的bean存在循環依賴則會拋異常
			 */
			if (isPrototypeCurrentlyInCreation(beanName)) {
				throw new BeanCurrentlyInCreationException(beanName);
			}
			// Check if bean definition exists in this factory.
			/**
			 * 找不到則從父容器中查找
			 */
			BeanFactory parentBeanFactory = getParentBeanFactory();
			if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
				// Not found -> check parent.
				String nameToLookup = originalBeanName(name);
				if (parentBeanFactory instanceof AbstractBeanFactory) {
					return ((AbstractBeanFactory) parentBeanFactory).doGetBean(
							nameToLookup, requiredType, args, typeCheckOnly);
				}
				else if (args != null) {
					// Delegation to parent with explicit args.
					return (T) parentBeanFactory.getBean(nameToLookup, args);
				}
				else if (requiredType != null) {
					// No args -> delegate to standard getBean method.
					return parentBeanFactory.getBean(nameToLookup, requiredType);
				}
				else {
					return (T) parentBeanFactory.getBean(nameToLookup);
				}
			}
			if (!typeCheckOnly) {
				markBeanAsCreated(beanName);
			}
			try {
				/**
				 * 父容器中也找不到該bean,則需要重新實例化
				 * 1,獲取要實例化bean的beanDefinition,
				 * 2,檢查bean的實例化需要依賴的其他bean
				 */
				final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
				checkMergedBeanDefinition(mbd, beanName, args);

				// Guarantee initialization of beans that the current bean depends on.
				String[] dependsOn = mbd.getDependsOn();
				if (dependsOn != null) {
					for (String dep : dependsOn) {
						/**
						 * 若給定的依賴 bean 已經註冊為依賴給定的bean
						 */
						if (isDependent(beanName, dep)) {
							throw new BeanCreationException(mbd.getResourceDescription(), beanName,
									"Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
						}
						registerDependentBean(dep, beanName);
						try {
							/**
							 * 遞歸調用getBean,優先創建依賴的bean
							 */
							getBean(dep);
						}
						catch (NoSuchBeanDefinitionException ex) {
							throw new BeanCreationException(mbd.getResourceDescription(), beanName,
									"'" + beanName + "' depends on missing bean '" + dep + "'", ex);
						}
					}
				}
				// Create bean instance.
				if (mbd.isSingleton()) {
					/**
					 * 通過調用DefaultSingletonBeanRegistry的getSingleton,從而調用核心方法createBean創建
					 */
					sharedInstance = getSingleton(beanName, () -> {
						try {
							return createBean(beanName, mbd, args);
						}
						catch (BeansException ex) {
							// Explicitly remove instance from singleton cache: It might have been put there
							// eagerly by the creation process, to allow for circular reference resolution.
							// Also remove any beans that received a temporary reference to the bean.
							destroySingleton(beanName);
							throw ex;
						}
					});
					bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
				}

				else if (mbd.isPrototype()) {
					// It's a prototype -> create a new instance.
					Object prototypeInstance = null;
					try {
						beforePrototypeCreation(beanName);
						prototypeInstance = createBean(beanName, mbd, args);
					}
					finally {
						afterPrototypeCreation(beanName);
					}
					bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
				}

				else {
					String scopeName = mbd.getScope();
					final Scope scope = this.scopes.get(scopeName);
					if (scope == null) {
						throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");
					}
					try {
						Object scopedInstance = scope.get(beanName, () -> {
							beforePrototypeCreation(beanName);
							try {
								return createBean(beanName, mbd, args);
							}
							finally {
								afterPrototypeCreation(beanName);
							}
						});
						bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
					}
					catch (IllegalStateException ex) {
						throw new BeanCreationException(beanName,
								"Scope '" + scopeName + "' is not active for the current thread; consider " +
								"defining a scoped proxy for this bean if you intend to refer to it from a singleton",
								ex);
					}
				}
			}
			catch (BeansException ex) {
				cleanupAfterBeanCreationFailure(beanName);
				throw ex;
			}
		}
		/**
		 * 檢查需要的bean類型是否符合
		 */
		// Check if required type matches the type of the actual bean instance.
		if (requiredType != null && !requiredType.isInstance(bean)) {
			try {
				T convertedBean = getTypeConverter().convertIfNecessary(bean, requiredType);
				if (convertedBean == null) {
					throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
				}
				return convertedBean;
			}
			catch (TypeMismatchException ex) {
				if (logger.isTraceEnabled()) {
					logger.trace("Failed to convert bean '" + name + "' to required type '" +
							ClassUtils.getQualifiedName(requiredType) + "'", ex);
				}
				throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
			}
		}
		return (T) bean;
	}

doGetBean的操作流程如下:

1,執行transformedBeanName方法轉換beanName

​ 傳遞的參數可能是bean的alias或者為FactoryBean,transformedBeanName執行的操作:(1)若傳進來的FactoryBean(FactoryBean以&作為前綴標記),去掉&修飾符。(2)經過(1)的處理后,有alias的bean則從aliasMap中獲取bean的原始beanName。

2,從容器的緩存中獲取bean

​ getSingleton先從spring三級緩存中的第一級singletonObjects(Map結構)中獲取,若不存在,則檢查該bean是否正在創建isSingletonCurrentlyInCreation(beanName)) ,正在創建的bean會從二級緩存earlySingletonObjects(Map結構)獲取。獲取到緩存的bean後會調用AbstractBeanFactory#getObjectForBeanInstance轉換bean的實例本身返回。因為從緩存中拿到的可能是factoryBean,所以getObjectForBeanInstance需要把是通過從緩存factoryBeanObjectCache獲取或通過factory.getObject()獲得相應的bean返回。

3,bean實例化前檢查

​ (1)先檢查是否原型模式下的bean是否存在循環依賴,是則會拋異常。

​ (2)檢查父類工廠(parentBeanFactory)是否存在,存在則從parentBeanFactory中遞歸調用doGetBean。

​ (3)獲取改bean的beanDefinition,檢查該bean實例化過程中是否涉及依賴了其他的bean,若是則遞歸調用getBean,優先創建依賴的bean。(涉及單例下的循環以來解決,下篇文章詳細介紹)。

​ (4)對創建bean代碼加synchronized和執行beforeSingletonCreation(beanName)前置處理。

3.3 創建前createBean邏輯

​ 經過前面的doGetBean的一輪檢查與準備后,便在AbstractAutowireCapableBeanFactory#createBean中開始bean的創建。

/**
	 * Central method of this class: creates a bean instance,
	 * populates the bean instance, applies post-processors, etc.
	 * 解析指定 BeanDefinition 的 class
	 * 處理 override 屬性
	 * 實例化的前置處理
	 * 創建 bean
	 * @see #doCreateBean
	 */
	@Override
	protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
			throws BeanCreationException {

		if (logger.isTraceEnabled()) {
			logger.trace("Creating instance of bean '" + beanName + "'");
		}
		RootBeanDefinition mbdToUse = mbd;

		// Make sure bean class is actually resolved at this point, and
		// clone the bean definition in case of a dynamically resolved Class
		// which cannot be stored in the shared merged bean definition.
		/**
		 * 解釋bean的class,看beanDefinition是否有class,否則load class
		 */
		Class<?> resolvedClass = resolveBeanClass(mbd, beanName);
		if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {
			mbdToUse = new RootBeanDefinition(mbd);
			mbdToUse.setBeanClass(resolvedClass);
		}
		/**
		 * 對bean不存在lookup-method 和 replace-method
		 * 標記其方法的overloaded為false
		 */
		// Prepare method overrides.
		try {
			mbdToUse.prepareMethodOverrides();
		}
		catch (BeanDefinitionValidationException ex) {
			throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(),
					beanName, "Validation of method overrides failed", ex);
		}

		try {
			/**
			 * 調用實現實現BeanPostProcessor的bean後置處理生成代理對象,
			 * 有代理對象則直接返回代理對象
			 */
			// Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.
			Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
			if (bean != null) {
				return bean;
			}
		}
		catch (Throwable ex) {
			throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,
					"BeanPostProcessor before instantiation of bean failed", ex);
		}

		try {
			/**
			 * 無需代理的bean實例化
			 */
			Object beanInstance = doCreateBean(beanName, mbdToUse, args);
			if (logger.isTraceEnabled()) {
				logger.trace("Finished creating instance of bean '" + beanName + "'");
			}
			return beanInstance;
		}
		catch (BeanCreationException | ImplicitlyAppearedSingletonException ex) {
			// A previously detected exception with proper bean creation context already,
			// or illegal singleton state to be communicated up to DefaultSingletonBeanRegistry.
			throw ex;
		}
		catch (Throwable ex) {
			throw new BeanCreationException(
					mbdToUse.getResourceDescription(), beanName, "Unexpected exception during bean creation", ex);
		}
	}

createBean的操作流程如下:

1,resolveBeanClass

​ 解釋beanDefinition的class,並且保存在beanDefinition中。

2,prepareMethodOverrides

​ 處理bean中的lookup-method (在單例bean用 @Lookup註解標記的方法,註解的方法返回的對象是原型)和 replace-method( 標記的方法,標記bean中A的方法被實現被另外一個實現MethodReplacer接口的B方法替代)。

3,resolveBeforeInstantiation

​ 調用實現實現BeanPostProcessor的bean後置處理生成代理對象,有代理對象則直接返回代理對象。(spring AOP則是基於此處實現)

3.4 bean的真正實例化createBeanInstance

​ 在AbstractAutowireCapableBeanFactory#createBeanInstance中,真正創建bean,源碼及註釋如下:

protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) {
		// Make sure bean class is actually resolved at this point.
		Class<?> beanClass = resolveBeanClass(mbd, beanName);
		if (beanClass != null && !Modifier.isPublic(beanClass.getModifiers()) && !mbd.isNonPublicAccessAllowed()) {
			throw new BeanCreationException(mbd.getResourceDescription(), beanName,
					"Bean class isn't public, and non-public access not allowed: " + beanClass.getName());
		}
		/**
		 * 通過提供supplier回調方法創建
		 */
		Supplier<?> instanceSupplier = mbd.getInstanceSupplier();
		if (instanceSupplier != null) {
			return obtainFromSupplier(instanceSupplier, beanName);
		}
		/**
		 * 通過工廠方法創建 bean 實例,可以是靜態工廠方法或者實例工廠
		 */
		if (mbd.getFactoryMethodName() != null) {
			return instantiateUsingFactoryMethod(beanName, mbd, args);
		}
		// Shortcut when re-creating the same bean...
		boolean resolved = false;
		boolean autowireNecessary = false;
		if (args == null) {
			synchronized (mbd.constructorArgumentLock) {
				/**
				 * 查找已經bean已經緩存解析的構造函數或者工廠方法
				 */
				if (mbd.resolvedConstructorOrFactoryMethod != null) {
					resolved = true;
					autowireNecessary = mbd.constructorArgumentsResolved;
				}
			}
		}
		/**
		 * 已經有緩存的構造函數或者工廠方法,直接實例化
		 */
		if (resolved) {
			if (autowireNecessary) {
				return autowireConstructor(beanName, mbd, null, null);
			}
			else {
				return instantiateBean(beanName, mbd);
			}
		}
		/**
		 * 通過實現BeanPostProcessor的代理類autowired的構造函數實例化
		 */
		// Candidate constructors for autowiring?
		Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
		if (ctors != null || mbd.getResolvedAutowireMode() == AUTOWIRE_CONSTRUCTOR ||
				mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args)) {
			return autowireConstructor(beanName, mbd, ctors, args);
		}
		/**
		 * 通過本身帶有autowired的構造函數實例化,通過調用反射newInstance實現
		 */
		// Preferred constructors for default construction?
		ctors = mbd.getPreferredConstructors();
		if (ctors != null) {
			return autowireConstructor(beanName, mbd, ctors, null);
		}
		/**
		 * 無參構造函數實例化,通過調用反射newInstance實現
		 */
		// No special handling: simply use no-arg constructor.
		return instantiateBean(beanName, mbd);
	}

由上述源碼可以看出,實例化bean操作流程如下:

1,如果存在 Supplier 回調,則通過提供supplier回調方法創建,如以下方式定義的bean:

@RunWith(SpringRunner.class)
@SpringBootTest(classes = Spring5Application.class)
public class BeanRegistrationTest {
    @Autowired
    private GenericWebApplicationContext context;
    
    context.registerBean(A.class, () -> new A());
}

2,如果存在工廠方法,則通過工廠方法創建 bean 實例,可以是靜態工廠方法或者實例工廠,如以下方式定義的bean:

public class AFactory implements FactoryBean<A> {
	@Override
	public A getObject() throws Exception {
		return new A();
	}
	@Override
	public Class<?> getObjectType() {
		return A.class;
	}
}
//或:
@Configuration
public class BeanConfigration {
	@Bean
	public A a(){
		return new A();
	}

}

3,已經有緩存的構造函數或者工廠方法,直接實例化。

4,以上三點都不存在,則使用帶參構造函數與無參構造函數實例化。如以下方式定義的bean:

@Commponet
public class A{}

4.總結

​ spring單例bean的實例化流程大概就是這樣,很多細節地方,包括循環依賴處理,bean屬性填充等細節點下一章介紹。

參考

  • 《Spring 源碼深度解析》- 郝佳
  • 《死磕spring源碼》-chenssy

查看更多文章關注公眾號:好奇心森林

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

※超省錢租車方案

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

※推薦台中搬家公司優質服務,可到府估價

akka-typed(4) – EventSourcedBehavior in action

  前面提到過,akka-typed中較重要的改變是加入了EventSourcedBehavior。也就是說增加了一種專門負責EventSource模式的actor, 最終和其它種類的actor一道可以完美實現CQRS。新的actor,我還是把它稱為persistentActor,還是一種能維護和維持運行狀態的actor。即,actor內部狀態可以存放在數據庫里,然後通過一組功能函數來提供對狀態的處理轉變,即持續化處理persistence。當然作為一種具備EventSourcedBehavior的actor, 普遍應有的actor屬性、方法、消息處理協議、監管什麼的都還必須存在。在這篇討論里我們就通過案例和源碼來說明一下EventSourcedBehavior是如何維護內部狀態及作為一種actor又應該怎麼去使用它。

我們把上一篇討論里購物車的例子拿來用,再增加一些消息回復response機制,主要是彙報購物車狀態:

object ItemInfo { case class Item(name: String, price: Double) } object MyCart { import ItemInfo._ sealed trait Command sealed trait Event extends CborSerializable sealed trait Response //commands
  case class AddItem(item: Item) extends Command case object PayCart extends Command case class CountItems(replyTo: ActorRef[Response]) extends Command //event
  case class ItemAdded(item: Item) extends Event case object CartPaid extends Event //state
  case class CartLoad(load: List[Item] = Nil) //response
  case class PickedItems(items: List[Item]) extends Response case object CartEmpty extends Response val commandHandler: (CartLoad, Command) => Effect[Event,CartLoad] = { (state, cmd) => cmd match { case AddItem(item) => Effect.persist(ItemAdded(item)) case PayCart => Effect.persist(CartPaid) case CountItems(replyTo) => Effect.none.thenRun { cart => cart.load match { case Nil => replyTo ! CartEmpty case listOfItems => replyTo ! PickedItems(listOfItems) } } } } val eventHandler: (CartLoad,Event) => CartLoad = { (state,evt) => evt match { case ItemAdded(item) => state.copy(load = item :: state.load) case CartPaid => state.copy(load = Nil) } } def apply(): Behavior[Command] = EventSourcedBehavior[Command,Event,CartLoad]( persistenceId = PersistenceId("10","1013"), emptyState = CartLoad(), commandHandler = commandHandler, eventHandler = eventHandler ) } object Shopper { import ItemInfo._ sealed trait Command extends CborSerializable case class GetItem(item: Item) extends Command case object Settle extends Command case object GetCount extends Command case class WrappedResponse(res: MyCart.Response) extends Command def apply(): Behavior[Command] = Behaviors.setup[Command] { ctx => val shoppingCart = ctx.spawn(MyCart(), "shopping-cart") val cartRef: ActorRef[MyCart.Response] = ctx.messageAdapter(WrappedResponse) Behaviors.receiveMessage { msg => msg match { case GetItem(item) => shoppingCart ! MyCart.AddItem(item) case Settle => shoppingCart ! MyCart.PayCart case GetCount => shoppingCart ! MyCart.CountItems(cartRef) case WrappedResponse(res) => res match { case MyCart.PickedItems(items) => ctx.log.info("**************Current Items in Cart: {}*************", items) case MyCart.CartEmpty => ctx.log.info("**************shopping cart is empty!***************") } } Behaviors.same } } } object ShoppingCart extends App { import ItemInfo._ val shopper = ActorSystem(Shopper(),"shopper") shopper ! Shopper.GetItem(Item("banana",11.20)) shopper ! Shopper.GetItem(Item("watermelon",4.70)) shopper ! Shopper.GetCount shopper ! Shopper.Settle shopper ! Shopper.GetCount scala.io.StdIn.readLine() shopper.terminate() }

實際上EventSourcedBehavior里還嵌入了回復機制,完成一項Command處理后必須回復指令方,否則程序無法通過編譯。如下:

private def withdraw(acc: OpenedAccount, cmd: Withdraw): ReplyEffect[Event, Account] = { if (acc.canWithdraw(cmd.amount)) Effect.persist(Withdrawn(cmd.amount)).thenReply(cmd.replyTo)(_ => Confirmed) else Effect.reply(cmd.replyTo)(Rejected(s"Insufficient balance ${acc.balance} to be able to withdraw ${cmd.amount}")) }

不過這個回復機制是一種副作用。即,串連在Effect產生之後立即實施。這個動作是在eventHandler之前。在這個時段無法回復最新的狀態。

說到side-effect, 如Effect.persist().thenRun(produceSideEffect): 當成功持續化event后可以安心進行一些其它的操作。例如,當影響庫存數的event被persist后可以馬上從賬上扣減庫存。

在上面這個ShoppingCart例子里我們沒有發現狀態轉換代碼如Behaviors.same。這隻能是EventSourcedBehavior屬於更高層次的Behavior,狀態轉換已經嵌入在eventHandler里了,還記着這個函數的款式吧  (State,Event) => State, 這個State就是狀態了。

Events persist在journal里,如果persist操作中journal出現異常,EventSourcedBehavior自備了安全監管策略,如下:

  def apply(): Behavior[Command] = EventSourcedBehavior[Command,Event,CartLoad]( persistenceId = PersistenceId("10","1013"), emptyState = CartLoad(), commandHandler = commandHandler, eventHandler = eventHandler ).onPersistFailure( SupervisorStrategy .restartWithBackoff(minBackoff = 10.seconds, maxBackoff = 60.seconds, randomFactor = 0.1) .withMaxRestarts(3) .withResetBackoffAfter(10.seconds))

值得注意的是:這個策略只適用於onPersistFailure(),從外部用Behaviors.supervisor()包嵌是無法實現處理PersistFailure效果的。但整個actor還是需要一種Backoff策略,因為在EventSourcedBehavior內部commandHandler,eventHandler里可能也會涉及一些數據庫操作。在操作失敗后需要某種Backoff重啟策略。那麼我們可以為actor增加監控策略如下:

  def apply(): Behavior[Command] = Behaviors.supervise( Behaviors.setup { ctx => EventSourcedBehavior[Command, Event, CartLoad]( persistenceId = PersistenceId("10", "1013"), emptyState = CartLoad(), commandHandler = commandHandler, eventHandler = eventHandler ).onPersistFailure( SupervisorStrategy .restartWithBackoff(minBackoff = 10.seconds, maxBackoff = 60.seconds, randomFactor = 0.1) .withMaxRestarts(3) .withResetBackoffAfter(10.seconds)) } ).onFailure( SupervisorStrategy .restartWithBackoff(minBackoff = 10.seconds, maxBackoff = 60.seconds, randomFactor = 0.1) .withMaxRestarts(3) .withResetBackoffAfter(10.seconds) )

現在這個MyCart可以說已經是個安全、強韌性的actor了。

既然是一種persistentActor,那麼持久化的管理應該也算是核心功能了。EventSourcedBehavior通過接收信號提供了對持久化過程監控功能,如:

 def apply(): Behavior[Command] = Behaviors.supervise( Behaviors.setup[Command] { ctx => EventSourcedBehavior[Command, Event, CartLoad]( persistenceId = PersistenceId("10", "1013"), emptyState = CartLoad(), commandHandler = commandHandler, eventHandler = eventHandler ).onPersistFailure( SupervisorStrategy .restartWithBackoff(minBackoff = 10.seconds, maxBackoff = 60.seconds, randomFactor = 0.1) .withMaxRestarts(3) .withResetBackoffAfter(10.seconds) ).receiveSignal { case (state, RecoveryCompleted) => ctx.log.info("**************Recovery Completed with state: {}***************",state) case (state, SnapshotCompleted(meta))  => ctx.log.info("**************Snapshot Completed with state: {},id({},{})***************",state,meta.persistenceId, meta.sequenceNr) case (state,RecoveryFailed(err)) => ctx.log.error("recovery failed with: {}",err.getMessage) case (state,SnapshotFailed(meta,err)) => ctx.log.error("snapshoting failed with: {}",err.getMessage) } } ).onFailure( SupervisorStrategy .restartWithBackoff(minBackoff = 10.seconds, maxBackoff = 60.seconds, randomFactor = 0.1) .withMaxRestarts(3) .withResetBackoffAfter(10.seconds) )

EventSourcedBehavior.receiveSignal是個偏函數:

  def receiveSignal(signalHandler: PartialFunction[(State, Signal), Unit]): EventSourcedBehavior[Command, Event, State]

下面是一個EventSourcedBehavior Signal 清單:

sealed trait EventSourcedSignal extends Signal @DoNotInherit sealed abstract class RecoveryCompleted extends EventSourcedSignal case object RecoveryCompleted extends RecoveryCompleted { def instance: RecoveryCompleted = this } final case class RecoveryFailed(failure: Throwable) extends EventSourcedSignal { def getFailure(): Throwable = failure } final case class SnapshotCompleted(metadata: SnapshotMetadata) extends EventSourcedSignal { def getSnapshotMetadata(): SnapshotMetadata = metadata } final case class SnapshotFailed(metadata: SnapshotMetadata, failure: Throwable) extends EventSourcedSignal { def getFailure(): Throwable = failure def getSnapshotMetadata(): SnapshotMetadata = metadata } object SnapshotMetadata { /** * @param persistenceId id of persistent actor from which the snapshot was taken. * @param sequenceNr sequence number at which the snapshot was taken. * @param timestamp time at which the snapshot was saved, defaults to 0 when unknown. * in milliseconds from the epoch of 1970-01-01T00:00:00Z. */ def apply(persistenceId: String, sequenceNr: Long, timestamp: Long): SnapshotMetadata =
    new SnapshotMetadata(persistenceId, sequenceNr, timestamp) } /** * Snapshot metadata. * * @param persistenceId id of persistent actor from which the snapshot was taken. * @param sequenceNr sequence number at which the snapshot was taken. * @param timestamp time at which the snapshot was saved, defaults to 0 when unknown. * in milliseconds from the epoch of 1970-01-01T00:00:00Z. */ final class SnapshotMetadata(val persistenceId: String, val sequenceNr: Long, val timestamp: Long) { override def toString: String = s"SnapshotMetadata($persistenceId,$sequenceNr,$timestamp)" } final case class DeleteSnapshotsCompleted(target: DeletionTarget) extends EventSourcedSignal { def getTarget(): DeletionTarget = target } final case class DeleteSnapshotsFailed(target: DeletionTarget, failure: Throwable) extends EventSourcedSignal { def getFailure(): Throwable = failure def getTarget(): DeletionTarget = target } final case class DeleteEventsCompleted(toSequenceNr: Long) extends EventSourcedSignal { def getToSequenceNr(): Long = toSequenceNr } final case class DeleteEventsFailed(toSequenceNr: Long, failure: Throwable) extends EventSourcedSignal { def getFailure(): Throwable = failure def getToSequenceNr(): Long = toSequenceNr }

當然,EventSourcedBehavior之所以能具備自我修復能力其中一項是因為它有對持久化的事件重演機制。如果每次啟動都需要對所有歷史事件進行重演的話會很不現實。必須用snapshot來濃縮歷史事件:

  def apply(): Behavior[Command] = Behaviors.supervise( Behaviors.setup[Command] { ctx => EventSourcedBehavior[Command, Event, CartLoad]( persistenceId = PersistenceId("10", "1013"), emptyState = CartLoad(), commandHandler = commandHandler, eventHandler = eventHandler ).onPersistFailure( SupervisorStrategy .restartWithBackoff(minBackoff = 10.seconds, maxBackoff = 60.seconds, randomFactor = 0.1) .withMaxRestarts(3) .withResetBackoffAfter(10.seconds) ).receiveSignal { case (state, RecoveryCompleted) => ctx.log.info("**************Recovery Completed with state: {}***************",state) case (state, SnapshotCompleted(meta))  => ctx.log.info("**************Snapshot Completed with state: {},id({},{})***************",state,meta.persistenceId, meta.sequenceNr) case (state,RecoveryFailed(err)) => ctx.log.error("recovery failed with: {}",err.getMessage) case (state,SnapshotFailed(meta,err)) => ctx.log.error("snapshoting failed with: {}",err.getMessage) }.snapshotWhen { case (state,CartPaid,seqnum) => ctx.log.info("*****************snapshot taken at: {} with state: {}",seqnum,state) true
          case (state,event,seqnum) => false }.withRetention(RetentionCriteria.snapshotEvery(numberOfEvents = 100, keepNSnapshots = 2)) } ).onFailure( SupervisorStrategy .restartWithBackoff(minBackoff = 10.seconds, maxBackoff = 60.seconds, randomFactor = 0.1) .withMaxRestarts(3) .withResetBackoffAfter(10.seconds) )

下面是本次示範的源碼:

build.sbt

name := "learn-akka-typed"

version := "0.1"

scalaVersion := "2.13.1"
scalacOptions in Compile ++= Seq("-deprecation", "-feature", "-unchecked", "-Xlog-reflective-calls", "-Xlint")
javacOptions in Compile ++= Seq("-Xlint:unchecked", "-Xlint:deprecation")

val AkkaVersion = "2.6.5"
val AkkaPersistenceCassandraVersion = "1.0.0"


libraryDependencies ++= Seq(
  "com.typesafe.akka" %% "akka-cluster-sharding-typed" % AkkaVersion,
  "com.typesafe.akka" %% "akka-persistence-typed" % AkkaVersion,
  "com.typesafe.akka" %% "akka-persistence-query" % AkkaVersion,
  "com.typesafe.akka" %% "akka-serialization-jackson" % AkkaVersion,
  "com.typesafe.akka" %% "akka-persistence-cassandra" % AkkaPersistenceCassandraVersion,
  "com.typesafe.akka" %% "akka-slf4j" % AkkaVersion,
  "ch.qos.logback"     % "logback-classic"             % "1.2.3"
)

application.conf

akka.actor.allow-java-serialization = on
akka {
  loglevel = DEBUG
  actor {
    serialization-bindings {
      "com.learn.akka.CborSerializable" = jackson-cbor
    }
  }
  # use Cassandra to store both snapshots and the events of the persistent actors
  persistence {
    journal.plugin = "akka.persistence.cassandra.journal"
    snapshot-store.plugin = "akka.persistence.cassandra.snapshot"
  }

}
akka.persistence.cassandra {
  # don't use autocreate in production
  journal.keyspace = "poc"
  journal.keyspace-autocreate = on
  journal.tables-autocreate = on
  snapshot.keyspace = "poc_snapshot"
  snapshot.keyspace-autocreate = on
  snapshot.tables-autocreate = on
}

datastax-java-driver {
  basic.contact-points = ["192.168.11.189:9042"]
  basic.load-balancing-policy.local-datacenter = "datacenter1"
}

ShoppingCart.scala

package com.learn.akka

import akka.actor.typed._
import akka.persistence.typed._
import akka.actor.typed.scaladsl.Behaviors
import akka.persistence.typed.scaladsl._
import scala.concurrent.duration._

object ItemInfo {
  case class Item(name: String, price: Double)
}

object MyCart {
 import ItemInfo._

  sealed trait Command
  sealed trait Event extends CborSerializable
  sealed trait Response

  //commands
  case class AddItem(item: Item) extends Command
  case object PayCart extends Command
  case class CountItems(replyTo: ActorRef[Response]) extends Command

  //event
  case class ItemAdded(item: Item) extends Event
  case object CartPaid extends Event

  //state
  case class CartLoad(load: List[Item] = Nil)

  //response
  case class PickedItems(items: List[Item]) extends Response
  case object CartEmpty extends Response

  val commandHandler: (CartLoad, Command) => Effect[Event,CartLoad] = { (state, cmd) =>
    cmd match {
      case AddItem(item) =>
        Effect.persist(ItemAdded(item))
      case PayCart =>
        Effect.persist(CartPaid)
      case CountItems(replyTo) =>
        Effect.none.thenRun { cart =>
          cart.load match {
            case Nil =>
              replyTo ! CartEmpty
            case listOfItems =>
              replyTo ! PickedItems(listOfItems)
          }
        }
    }
  }

  val eventHandler: (CartLoad,Event) => CartLoad = { (state,evt) =>
    evt match {
      case ItemAdded(item) =>
         state.copy(load = item :: state.load)
      case CartPaid =>
        state.copy(load = Nil)
    }
  }

  def apply(): Behavior[Command] =
    Behaviors.supervise(
      Behaviors.setup[Command] { ctx =>
        EventSourcedBehavior[Command, Event, CartLoad](
          persistenceId = PersistenceId("10", "1013"),
          emptyState = CartLoad(),
          commandHandler = commandHandler,
          eventHandler = eventHandler
        ).onPersistFailure(
          SupervisorStrategy
            .restartWithBackoff(minBackoff = 10.seconds, maxBackoff = 60.seconds, randomFactor = 0.1)
            .withMaxRestarts(3)
            .withResetBackoffAfter(10.seconds)
        ).receiveSignal {
          case (state, RecoveryCompleted) =>
            ctx.log.info("**************Recovery Completed with state: {}***************",state)
          case (state, SnapshotCompleted(meta))  =>
            ctx.log.info("**************Snapshot Completed with state: {},id({},{})***************",state,meta.persistenceId, meta.sequenceNr)
          case (state,RecoveryFailed(err)) =>
            ctx.log.error("recovery failed with: {}",err.getMessage)
          case (state,SnapshotFailed(meta,err)) =>
            ctx.log.error("snapshoting failed with: {}",err.getMessage)
        }.snapshotWhen {
          case (state,CartPaid,seqnum) =>
            ctx.log.info("*****************snapshot taken at: {} with state: {}",seqnum,state)
            true
          case (state,event,seqnum) => false
        }.withRetention(RetentionCriteria.snapshotEvery(numberOfEvents = 100, keepNSnapshots = 2))
      }
    ).onFailure(
      SupervisorStrategy
        .restartWithBackoff(minBackoff = 10.seconds, maxBackoff = 60.seconds, randomFactor = 0.1)
        .withMaxRestarts(3)
        .withResetBackoffAfter(10.seconds)
    )
}

object Shopper {

  import ItemInfo._

  sealed trait Command extends CborSerializable

  case class GetItem(item: Item) extends Command
  case object Settle extends Command
  case object GetCount extends Command

  case class WrappedResponse(res: MyCart.Response) extends Command

  def apply(): Behavior[Command] = Behaviors.setup[Command] { ctx =>
    val shoppingCart = ctx.spawn(MyCart(), "shopping-cart")
    val cartRef: ActorRef[MyCart.Response] = ctx.messageAdapter(WrappedResponse)
    Behaviors.receiveMessage { msg =>
      msg match {
        case GetItem(item) =>
          shoppingCart ! MyCart.AddItem(item)
        case Settle =>
          shoppingCart ! MyCart.PayCart
        case GetCount =>
          shoppingCart ! MyCart.CountItems(cartRef)
        case WrappedResponse(res) => res match {
          case MyCart.PickedItems(items) =>
            ctx.log.info("**************Current Items in Cart: {}*************", items)
          case MyCart.CartEmpty =>
            ctx.log.info("**************shopping cart is empty!***************")
        }
      }
      Behaviors.same
    }
  }

}


object ShoppingCart extends App {
  import ItemInfo._
  val shopper = ActorSystem(Shopper(),"shopper")
  shopper ! Shopper.GetItem(Item("banana",11.20))
  shopper ! Shopper.GetItem(Item("watermelon",4.70))
  shopper ! Shopper.GetCount
  shopper ! Shopper.Settle
  shopper ! Shopper.GetCount
  scala.io.StdIn.readLine()

  shopper.terminate()

}

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※回頭車貨運收費標準

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※推薦評價好的iphone維修中心

※教你寫出一流的銷售文案?

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

殼牌石油拚減碳 誓言最遲2050年達零排放

摘錄自2020年4月16日聯合報報導

國際石油天然氣巨擘荷蘭皇家殼牌集團(Royal Dutch Shell)今(16日)誓言,在2050年前要達成「碳中和」(Carbon Neutral)目標,和競爭對手英國石油公司(BP)的承諾一樣。

法新社報導,殼牌執行長范柏登(Ben vanBeurden)在聲明中表示,社會對於氣候變遷的期許瞬息萬變,殼牌需要再進一步自我要求,計畫最晚在2050年成為零排放的能源企業。殼牌將在2050年前把自家能源產品的「淨碳足跡」減少約65%;在2030年減少30%。

溫室氣體
能源議題
全球變遷
氣候變遷
能源轉型
國際新聞
殼牌
減碳宣言
零排放
石油

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※推薦評價好的iphone維修中心

網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!

城市SUV就不能越野?進山後這台車性格大變

無疆界。盡馳騁本次試駕的地點選址是廣州王子山,奧迪本次並沒有專門為試駕活動搭建一塊可以輕鬆通過考驗的場地,而是以不常規的純天然全路況山林作為試驗全新奧迪Q7的考試場。在鋪裝路面上,將空氣懸架調節至最低狀態,此時離地間隙為186mm,車身姿態更低,高速狀態下行駛異常穩定,2。

廣州王子山奧迪Q7任性越野

奧迪Q7的形象一直以來都給人一種優雅穩重,大氣成熟的印象。似乎它的車主就應該西裝革履一本正經的出入五星級酒店和出席高檔商務場所。然而很多人並不知道,當它脫離了城市的喧囂和繁華之後,在崎嶇難行的非鋪裝路面,奧迪Q7也會露出崢嶸任性的一面。

初現肌肉——粗獷中的精緻

全新奧迪Q7上市已經有一段時間,相比較上一代奧迪Q7,全新的奧迪Q7在外觀層面進行了“全面瘦身”,車身尺寸有所減小,儘管在很多人眼裡似乎全新的奧迪Q7少了一分霸氣,但是個人認為,更加平直簡練的線條,使得全新奧迪Q7更多了一分精緻感。如果說老款的奧迪Q7更像一個兇猛的肌肉男,那麼全新奧迪Q7則更像一個肌肉線條更加勻稱卻不失力量感的健美先生。

凸顯內涵——小尺寸中的大肚量

全新奧迪Q7的內飾採用了全新的設計語言,整體造型設計更加簡潔明快,作為一款奧迪品牌旗艦型的SUV,細節之處的精細程度毋庸置疑。

鋁製和木紋飾板的搭配,彰顯了豪華感的同時更體現出現代工藝氣息,搭配上第二代的MMI智能信息系統以及點火之後緩緩升起的8.3英寸液晶显示屏,檔次感豪華感與科技感並存的車廂確實讓人覺得相當高級。

不少人會覺得,全新Q7的車身尺寸全面縮水,會不會提升Q7車內的乘坐壓抑感,帶着疑問小編也是坐進全新Q7的後排體驗一番,實際感受過後覺得並不會,全新Q7的長寬高數據為:5069*1968*1716mm,軸距長為3001mm,空間足夠寬敞,加之座椅十分舒適度也算不錯,駕駛位坐姿設計合理,視野盲區不大,全新Q7的駕乘感受在同級當中可謂是處於領先水準。

裝備齊全才能游刃有餘

全新奧迪Q7的標準離地間隙達到201mm,在一般的道路通過性上已經有着非常紮實的基礎,並且搭載quattro全時四驅系統以及可變式空氣懸挂(非頂配車型需選裝),在不同的道路模式下有着不同的行駛姿態,以及百公里加速僅需7.22秒的2.0T渦輪增壓發動機,強悍的性能和齊全的裝備,讓奧迪Q7在面對極限路況時才有着充足的信心和底氣。

無疆界;盡馳騁

本次試駕的地點選址是廣州王子山,奧迪本次並沒有專門為試駕活動搭建一塊可以輕鬆通過考驗的場地,而是以不常規的純天然全路況山林作為試驗全新奧迪Q7的考試場。

在鋪裝路面上,將空氣懸架調節至最低狀態,此時離地間隙為186mm,車身姿態更低,高速狀態下行駛異常穩定,2.0T的發動機並不會顯得拖沓無力,隨着油門的深入,到達1600轉之時所迸發出的370牛米的峰值扭矩,儘管它是一台大尺寸豪華SUV,但也能讓駕駛者充分體驗一把速度與激情。

既然作為一款搭載着全時四驅和可變式空氣懸架的大尺寸SUV,在王子山這種純天然的山路中行進既是作為一個較為嚴酷的考驗項目,也是全新Q7展現強悍性能的用武之地。面對着崎嶇的道路環境,將氣動懸架的高度提升至最高狀態(261mm),高聳的底盤極大降低了因為道路石塊而托底的風險。

得益於調校得恰到好處的轉向手感,在速度不快的越野道路上,大尺寸的Q7顯得異常靈活,穩定的車身姿態使得在路況較為驚險的非鋪裝路面上有着十足的信心支撐。

王子山上的路況十分複雜,由於嶺南一帶潮濕的氣候,儘管白天陽光十分燦爛,但是路面依然有不少地方非常濕滑,甚至還有一些淌流着的小溪和溝壑需要跨越,但是全新奧迪Q7面對這些對於普通城市SUV來說已經算是極限的道路,依然顯得游刃有餘,勝似閑庭信步。

這是由於奧迪Q7的前後橋都配備了了開放式差速器和輪間限滑系統,並且quattro四驅在動力配比上日常是前後橋40:60的比例分攤動力輸出,而在極限狀況下可以使得前橋最大動力供給達到70%,而後橋可支配動力最高可以達到85%,極大保證了全新Q7面對惡劣路況的適應性。

檔次不減;盛名不負

以往對於奧迪Q7的形象一直是一台大品牌、高品質、高檔次的豪華型城市SUV,似乎它的一切就應該那麼有條不紊,似乎它就一定是一款在公路上馳騁的大塊頭豪華車。

然而畢竟作為一款旗艦型全時四驅SUV,奧迪Q7的先天基因依然流淌着一款SUV該有的性格與野性,不受“城市SUV”標準的束縛、不受“全民SUV”時代的限制,憑藉著強悍的性能表現,奧迪Q7,一款豪華品牌旗艦SUV,除了可以帶來頂級奢華的高檔感以外,照樣可以讓車主縱情翻山越嶺感受喧囂以外的非凡。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計最專業,超強功能平台可客製化

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

※教你寫出一流的銷售文案?

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家公司費用怎麼算?

動力橫評|跑進10秒 海馬S5領先不止一點

在0-100公里加速上,海馬S5-9。81秒、長安CS35-11。02秒、寶駿560-12。01秒。從加速上來看,在8萬級別中,能進入10秒的真是屈指可數。相比長安CS35和寶駿560來說,在整個加速過程中,海馬S5在起步的瞬間動力來得更加直接,而且在中後段也不會出現乏力情況。

在市場表現上,售價8萬至10萬的8萬級SUV近兩年相當火爆。針對上述情況,找了能見度比較高的三款八萬級熱銷車型,在動力方面做個實測對比,(為什麼對比動力?因為注重內涵,外觀下次測)這次對比的三款車型分別是:長安CS35、海馬S5、寶駿560、均是1.5T動力總成

從上表的綜合數據來看,三者的動力系統都算主流,不謙虛地說也算是這個級別里相對靠前的,不過海馬S5的參數表現都要略優於其它兩款車型。三款對比車型均採用1.5T渦輪增壓發動機,海馬S5的最大馬力為163ps、最大扭矩223N·m;寶駿560的最大馬力150ps,最大扭矩230N·m;長安CS35的最大馬力156ps,最大扭矩215N·m。從賬面數據來看,海馬S5的優勢非常明顯。

此外,海馬S5的1.5T渦輪增壓發動機採用了新一代小慣量渦輪,恭弘=叶 恭弘輪採用最新一代合金材料,重量更輕,慣量降低35%,有效減小渦輪遲滯,提高系統響應性,滿足低轉速大扭矩驅動,發動機1600轉時就能輸出90%最大扭矩。

從發動機的動力表現,三者在實際駕駛中,均有着不錯的親和力,起步反饋輕快,低速行駛時動力與變速箱的配合也相當不錯。但海馬S5在動力上的體驗會來得更加地直接,當發動機轉速僅為1000rpm時,就能體驗到渦輪介入,在1800rpm狀態下,即能體驗到223N·m的最大扭矩輸出狀態,且能一直保持到4000rpm,動力輸出水平在同級車型中相當出色,且最大扭矩轉速區間很寬。相比之下,寶駿560的1.5T發動機,在2000rpm時才能達到最大扭矩輸出,最大扭矩轉速區間為2000-3800rpm,明顯劣於海馬S5。

在0-100公里加速上,海馬S5-9.81秒、長安CS35-11.02秒、寶駿560-12.01秒。從加速上來看,在8萬級別中,能進入10秒的真是屈指可數。相比長安CS35和寶駿560來說,在整個加速過程中,海馬S5在起步的瞬間動力來得更加直接,而且在中後段也不會出現乏力情況。

在剎車對比測試中,海馬S5進入了40米內,如此優秀的剎車成績,可以讓它在大部分同級別、同價位的競爭對手面前炫耀一番。須知道這個級別大部分車型的100-0km/h剎車距離都是40米開外,有的甚至是43米之多。除了剎車成績優秀以外,其剎車踏板反饋回來的腳感也很棒,不僅虛位小,而且回饋力度比較均勻線性。

從動力輸出到制動力的表現,可以看出在三款車型當中,海馬S5數據和實力明顯優於寶駿560和長安CS35。

寶駿560-低速扭矩力量足夠,1擋到4擋的提速感覺明顯有力,但是進入5擋,時速超過100公里/小時的時候,提速就會顯得很乏力。

長安CS35-發機機是三菱的4G15T改造而來,加速只能說夠用,不能深踩,高轉速時發動機的聲音讓人奔潰。

海馬S5-上車地板油S檔,兩千轉加速明顯,還有推背感,雖然不算強,但能有這個的體驗反饋給你,後段的力量儲備也是相對充足,在賽道直路最快跑165時速,底盤不會給你坐船的感覺,懸挂也是支撐到位,在高轉速時,發動機也是會有聲音但是,在一個可接受範圍。

回看市場,如今小型SUV由不入流,到成為主流,最多也不過5年,但是市場卻發生了翻天覆地的變化的變化,如今的小型SUV市場競爭已然也到了白熱化的地步。縱觀國內小型SUV細分市場,本田、現代/起亞、別克、鈴木、福特、雪佛蘭、Jeep等國際大廠都推出了合資小型SUV,在品質上力壓自主車型,同時價錢也在不斷下探,新老車型的格局正在逐漸形成,而這種格局勢必會引起小型SUV市場的一些變革,花無百日紅,新生代小型SUV正在陸續到來,如果產品力可以經得起考驗的情況下,小型SUV市場或將很快迎來一次大換血,讓我們拭目以待吧。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

※超省錢租車方案

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

※推薦台中搬家公司優質服務,可到府估價

萬萬想不到 20萬的MPV超越40萬房車享受

在車上對坐面談彷彿是挺不錯的事情,邁特威最大的亮點是內部空間和座椅的靈活擴展性,二排座椅支持旋轉移動,但反着坐的人就不舒服了,中間圓形桌板使得第三排乘客出入比較困難,座椅設計過高不符合國人身材,長時間乘坐舒適性難保障,不實用。

前言

現在除了SUV車型最火爆外,商務精英人士最喜愛的莫過於MpV車型了,商用出差接客戶有面子,空間夠大夠舒適,一舉兩得,眾所周知,在歐洲市場,福特途睿歐和大眾邁特威已經是對老冤家了,而進口后的邁特威價格幾乎是國產後途睿歐的兩倍,誰更有性價比呢?

最近隨着自己業績越來越好,小李思索着想買一台車,畢竟自己是業務員,沒個車接客戶談商務合作什麼的不方便,從小就特別喜歡MpV的小李,就特別想買一台MpV,於是把目標鎖定在兩台車上:福特途睿歐、大眾邁特威。

方方正正的車身造型不禁讓人聯想到以前的全順、依維柯那種輕客,就有點與時代脫軌的節奏,而且給人一種低檔的感覺,還有令人有些審美疲勞的家族式前臉沒什麼改進,不過挺耐看的。

再看途睿歐則給人一種很豪邁的視覺感受,車身線條很硬朗但沒有硬邦邦的感覺,車側突出的輪眉凸顯其壯碩的的身材,柔中帶剛更顯威武,前臉有着萌萌噠的造型,很和藹可親,是一輛宜商宜旅的車子。

老爸家裡那台老捷達確實實用,兢兢業業服務了好多年,這點在大眾邁特威內飾上一樣,採用套娃的設計,大量的鋼琴烤漆面板和方方正正的設計元素和外觀比較搭配,營造了比較高檔的感覺,但是沒什麼新意,開着居然和轎車是一樣的Feel。

途睿歐的內飾造型層次感更豐富,看起來並不會出現所謂的視覺疲勞感,操作區域幾乎圍繞駕駛者四周,實用人性化為上,上深下淺的配色很有商務風格,給人溫馨舒適的乘坐體驗,低矮的左右側窗線設計使得兩側視野很好,很容易上手。

我們來看一下配置上的差異,邁特威會佔有優勢,但相差不大的配置但一想到相差20多萬的價格,突然感覺有點藍瘦,像天窗和導航系統這麼基本的配置,邁特威要去到54.98萬的車型才有配備。

而途睿歐20.39萬車型就有了,前後排自動空調是全系標配,為了乘員上下更方便,還配備了側踏板,還有貼心的後排220v電源支持手提筆記本等設備的使用,能及時收發郵件和處理文件。

旋轉、跳躍我閉着眼。。。在車上對坐面談彷彿是挺不錯的事情,邁特威最大的亮點是內部空間和座椅的靈活擴展性,二排座椅支持旋轉移動,但反着坐的人就不舒服了,中間圓形桌板使得第三排乘客出入比較困難,座椅設計過高不符合國人身材,長時間乘坐舒適性難保障,不實用。

4976*2032*1990mm的車身尺寸使得途睿歐比邁特威大了一圈,採用2+2+3的座椅布局,中間留有通道,橫縱向空間更大,以往一般MpV比較雞肋的第三排空間,途睿歐表現卻很出色,完全是三個獨立座椅,不會再出現肩膀碰肩膀的尷尬情況,儲物空間隨手可及,驚人的後備箱空間即使在常規狀態下也達到1360L,實用性上更出色。

話說高端車型為什麼開起來那麼舒服,像奔馳奧迪等高端車型上配備都配備了空氣懸挂,可以調節懸挂的軟硬,能適應不同路況,而途睿歐採用了同級罕見的RAS后空氣懸挂,隨時隨地享受最舒適的駕乘體驗;人機工程學上做得很轎車化,座椅可以調得比較低接近SUV的坐姿,比較垂直的方向盤角度,掄方向比搓麻將還要順滑。

麵包車開起來是什麼感覺的,是不是重心太高,有點發飄,邁特威採用了後半拖曳臂獨立式懸挂,雖然有DCC模式可調,但感覺跨度不太明顯,軟硬有點兩極分化,始終把握不好合適的度,不過舒適性方面還是有一貫大眾車的風格。

賬面數據上EA888發動機+7擋雙離合的組合表現更為出色,用在高爾夫Gti是挺猛的,但拖動邁特威這2.5噸重的車子起步似乎有點吃力,必要時刻還得靠S擋來解決動力不足的問題,還有考慮到用車成本上,油耗和保養費用也是不佔優勢的。

而途睿歐搭載的是福特2.0T EcoBoost發動機,與路虎、捷豹等高端車型使用的是同宗同源的,燃油經濟性更佳,動力也相差無幾,還一個令人讚歎的就是它整體的NVH水平,不管是發動機還是底盤,都達到了乘用車的優良水平,綜合性能更強,搭配5擋手動變速箱,可靠性更佳。

再糾正下小李子的想法,進口車所交的各種關稅、消費稅、增值稅後導致邁特威的價格都去到40多萬了,而途睿歐國產後的價格就完全不用這些花費,性價比更高更接地氣,所以勸你還是移情別戀吧。

兩朋友笑日:你小子現在知道的挺多啊。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※回頭車貨運收費標準

※產品缺大量曝光嗎?你需要的是一流包裝設計!

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※推薦評價好的iphone維修中心

※教你寫出一流的銷售文案?

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

深入理解JVM(③)判斷對象是否還健在?

前言

因為Java對象主要存放在Java堆里,所以垃圾收集器(Garbage Collection)在對Java堆進行回收前,第一件事情就是要確定這些對象之中哪些還“存活”着,哪些已經“死去”(不被引用了)。

判斷對象是否健在的算法

1.引用計數算法

引用計數算法,很容易理解,在對象中添加一個引用計數器,每有一個地方引用它時,計數器值就加一;當引用失效是,計數器值就減一;任何時刻計數器為零的對象就是不可以能再被使用的對象
引用計數算法的原理簡單,判定效率也很高。市面上也確實有一些技術使用的此類算法來判定對象是否存活,像ActionScript 3 的FlashPlayer、Python語言等。但是在主流的Java虛擬機裏面都沒有選用引用計算法來管理內存,主要是使用此算法時,必須要配合大量的額外處理才能保證正確的工作,例如要解決對象之間的相互循環引用的問題。

public class OneTest {

    public Object oneTest = null;

    private static final int _1MB = 1024 * 1024;

    private byte[] bigSize = new byte[256 * _1MB];


    /**
     * 這個成員屬性的唯一意義就是占點內存,以便能在GC日誌中看清楚是否有回收過。
     */
    @Test
    public void testGC(){

        OneTest test1 = new OneTest();
        OneTest test2 = new OneTest();

        test1.oneTest = test2;
        test2.oneTest = test1;

        test1 = null;
        test2 = null;

        // 假設在這行發生GC,test1和test2是否能被回收?
        System.gc();

    }

}

分析代碼,test1和test2對象都被設置成了null,在後面發生GC的時候,如果按照引用計數算法,這兩個對象雖然都被設置成了null,但是test1引用了test2,test2又引用了test1,所以這兩個對象的引用計數值都不為0,所以都不會被回收,但是真正的實際運行結果是,這兩個對象都被回收了,這也說明HotSpot虛擬機並不是用引用計數法來進行的內存管理。

2. 可達性分析算法

當前主流的商用程序語言(Java、C#等),都是通過可達性分析(Reachability Analysis)算法來判斷對象是否存活的。這個算法的基本思路就是通過一一系列稱為“GC Roots” 的根對象作為起始節點集,從這些節點開始根據引用關係向下搜索,搜索走過的的路徑稱為“引用鏈”(Reference Chain),如果某個對象到GC Roots 間沒有任何引用鏈相連,或者從GC Roots 到這個對象不可達時,則證明此對象是不可能再被使用的。
如下圖,object10、object11、object12這三個對象,雖然互相有關聯,但是它們到GC Roots是不可達的,因此它們會被判定為可回收的對象。

在Java程序中,固定可作為GC Roots 的對象包括以下幾種:

  • 在虛擬機棧(棧幀中的本地變量表)中引用的對象,譬如各個現場被調用的方法堆棧中使用到的參數、局部變量、臨時變量等。
  • 在方法區中類靜態屬性引用的對象,譬如Java類的引用類型靜態變量。
  • 在方法區中常量引用的對象,譬如字符串常量池(String Table)里的引用。
  • 在本地方法棧中JNI(即通常所說的Native方法)引用的對象。
  • Java虛擬機內部的引用,如基本數據類型對應的Class對象,一些常駐的異常對象(NullPointException、OutOfMemoryError)等,還有系統類加載器。
  • 所有被同步鎖(synchronized關鍵字)持有的對象。
  • 反映Java虛擬機內部情況的JMXBean、JVMTI中註冊的回調、本地代碼緩存等。
    除了這些固定的GC Roots集合以外,根據垃圾收集器以及當前回收的呢村區域不同,還會有其他對象“臨時性”的加入,如果只針對Java堆中某一塊兒區域發起垃圾收集時(例如只針對年輕代的垃圾收集),必須考慮到當前區域內的對象是否有被其他區域的對象所引用,這個時候就需要把這些關聯區域的對象一併加入GC Roots集合中,來保證可達性分析的正確性。

重申引用

無論是通過引用計數算法判斷對象的引用數量,還是通過可達性分析算法判斷對象是否引用鏈可達,判斷對象是否存活都和“引用”離不開關係。在JDK1.2之前,Java里對引用的概念是:如果reference類型的數據中存儲的數值代表的是另外一塊兒內存的地址,就稱該reference數據是代表某塊內存、某個對象的引用。
在JDK1.2版之後,Java對引用的概念進行了擴充,將引用分為強引用(Strongly Reference)、軟引用(Soft Reference)、弱引用(Weak Reference)、虛引用(Phantom Reference)4種,這4種引用強度依次逐漸減弱。

  • 強引用是最傳統的“引用”的定義,指引用複製,即類似
Object obj = new Object()

這種引用關係。無論在任何情況下,只要強引用關係還存在,垃圾收集器就不會回收掉被引用的對象。

  • 軟引用是用來描述一些還有用,但非必須的對象。在系統發生內存溢出前,會先對軟引用對象進行第二次回收,如果回收后還沒有足夠的內存,才會拋出內存溢出的異常。
  • 弱引用也是用來描述那些非必須的對象,但是它的強度比軟引用更弱一些,弱引用的對象,只能生存到下一次垃圾收集發生為止。當垃圾收集器開始工作,無論當前內存是否足夠,都會回收掉只被弱引用關聯的對象。
  • 虛引用也稱為“幽靈引用”或“幻影引用”,它是最弱的一種引用關係。為一個對象設置虛引用關聯的唯一目的只是為了能在這個對象被收集器回收時收到一個系統通知。

判斷對象是生是死的過程

即使在可達性分析算法中,判斷為不可達的對象,也不是“非死不可”的,要真正宣告一個對象死亡,至少要經歷兩次標記過程:

  • 如果第一次對象在進行可達性分析后發現與GC Roots 不可達,將進行第一次標記。
  • 隨後對此對象進行一次是否有必要執行finalize()方法進行篩選,假如對象沒有覆蓋finalize()方法,或者finalize()方法已經被虛擬機調用過,都視為“沒有必要執行”。
    如果對象被判定有必要執行finalize()方法,會將對象放置在一個名為F-Queue的隊列中,並在由一條由虛擬機自動建立的、低調度的線程區執行它們的finalize()方法。但並不承諾一定會等待它們運行結束。

需要注意的是:任何一個對象的finalize()方法都只會被系統自動調用一次,如果對象面臨第二次回收,它的finalize()方法不會被再次執行。
還有一點就是Java官方已經明確聲明不推薦手動調用finalize()方法了,因為它的運行代價高昂,不確定性大,無法保證各個對象的調用順序,並且finanlize()能做的所有工作,使用try-finally或其他方式都可以做的更好、更及時。

回收方法區

方法區垃圾收集的“性價比”通常比較低,並且方法區回收也有過於苛刻的判定條件。
方法區的垃圾收集主要回收兩部分內容:廢棄的常量不再使用的類型,回收廢棄常量時,如果當前系統沒有一個常量的值是當前常量值,且虛擬機中也沒有其他地方引用這個常量。如果這個時候發生垃圾回收,常量就會被系統清理出常量池。
判定一個類型是否屬於“不再使用的類”的條件就比較苛刻了,要同時滿足如下三個條件:

  • 該類所有的實例都已經被回收,也就是Java堆中不存在該類及其任何派生子類的實例。
  • 加載該類的類加載器已經被回收,這個條件除非是經過精心設計的可替換類加載器的場景,如OSGi、JSP的沖加載等,否則通常很難達成的。
  • 該類對應的java.lang.Class對象沒有在任何地方被引用,無法在任何地方通過反射訪問該類的方法。

同時滿足了上述的三個條件后,也只是被允許進行回收了,關於是否要對類型進行回收還要對虛擬機進行一系列的參數設置,這裏就不贅述了,感興趣的可以自己去查詢。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※推薦評價好的iphone維修中心

網頁設計最專業,超強功能平台可客製化

※別再煩惱如何寫文案,掌握八大原則!