標籤: 台北網頁設計

  • 不只搶衛生紙!紐約民眾瘋「認養寵物」…收容所全沒毛孩了

    摘錄自2020年3月26日ETtoday報導

    新型肺炎疫情近日在美大爆發,紐約州長古莫(Andrew Cuomo)要求居民盡可能待在家,結果因民眾在家防疫需要寵物陪伴紓壓,導致出現收容所的狗全被認養走的情況。

    紐約市動物福利組織「Muddy Paws Rescue」、「Best Friends Animal Society」近日即指出,在這兩星期內,申請認領犬貓的數量比平常多出10倍,紐約民眾顯然是將飼養貓狗視為防疫紓解壓力的方法。

    「Muddy Paws Rescue」總監安娜(Anna Lai)表示,現在我們機構完全沒有狗可供認領,這是個大問題。「Best Friends Animal Society」執行官朱莉(Julie Castle)說,民眾成群結隊的來認養寵物,我沒看過美國人民這麼團結。

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

    【其他文章推薦】

    USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

    台北網頁設計公司這麼多該如何選擇?

    ※智慧手機時代的來臨,RWD網頁設計為架站首選

    ※評比南投搬家公司費用收費行情懶人包大公開

    ※回頭車貨運收費標準

  • 法國罕見地震規模5.4 近16年來最強

    摘錄自2019年11月11日中央社報導

    法國東南部11日近午時分發生一起芮氏規模5.4的地震,這個地區罕有超過規模5的地震,當地民眾感受特別深刻,已知有4人受傷,其中一人重傷。

    法新社報導,巴黎地球物理研究所(IPGP)史特拉斯堡辦公室的學者梅格哈威(Mustapha Meghraoui)表示,這一地區的地震規模極少超過5,可以說這起地震很罕見。

    震央鄰近克魯亞斯(Cruas)核電站及特里卡斯坦(Tricastin)核電站,法國電力集團(EDF)晚間決定暫停克魯亞斯核電站的反應爐,以便進行預防性檢測;法國核能安全署(ASN)表示,地震並未在相關設施造成顯著損壞,但仍將檢視反應爐重啟的條件。

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

    【其他文章推薦】

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

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

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

    ※超省錢租車方案

  • 最新研究:全球「水塔」面臨多重威脅 喜馬拉雅列亞洲最脆弱

    摘錄自2019年12月10日中新網北京報導

    據中國科學院青藏高原研究所消息,括中國科學家在內的全球科學家對被稱為「水塔」—地球78個高山冰川水系統的最新研究評估顯示,全球「水塔」正面臨氣候變化、人口增長、水資源管理不善、其他地緣政治因素等多重威脅,形勢岌岌可危。

    這項最新評估研究由全球32位科學家合作撰寫,獲得中科院院士、冰川學家姚檀棟牽頭的中科院專項資助,並發表於《自然》期刊。

    地球78個基於高山冰川的水系統被稱為高山「水塔」,其通過冰川、積雪、湖泊和河流來儲藏與運送水,為全球19億人(約佔全球總人口的1/4)提供水資源。亞洲以印度河「水塔」受依賴度最高也最為脆弱,它由喜馬拉雅山脈的廣大地區組成,覆蓋阿富汗、中國、印度和巴基斯坦部分地區。

    姚檀棟提醒說,如果全球氣溫升幅超過攝氏2度,亞洲「水塔」氣溫則會劇增至4度,到2060-2070年會出現更大規模的冰川退卻。冰川消減後,以季節性冰川融水補給為主的河流能夠提供的淡水量也會隨之減少,下游地區人口可能會面臨淡水資源減少的問題。

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

    【其他文章推薦】

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

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

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

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

  • 北海道降雪量不到往年一半 札幌積雪僅9厘米

    摘錄自2020年1月9日星島日報報導

    日本北海道今個冬天降雪異常,上月降雪量不到往年一半,創1961年統計以來新低紀錄,札幌雪祭月底就要開幕,主辦單位正緊急到30公里外的鄉鎮俱知安町及京極町等地「調雪」到札幌市大通公園,讓參加者製作冰雕。

    札幌市中央區的積雪量到周四上午9時止只有9厘米,較往年同期的44厘米大幅減少,雪祭通常需要3000輛10噸重大卡車的雪量。

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

    【其他文章推薦】

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

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

    南投搬家公司費用需注意的眉眉角角,別等搬了再說!

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

  • Suzuki Swift跟進導入輕油電動力 小改款車型預計4月日本首發

    摘錄自2020年3月18日ETtoday報導

    2020年暫訂沒有改款幅度較大的新世代車型問世,但近年來憑藉著堅強的「小車大軍」席捲市場的Suzuki,也著手針對品牌車款進行小改款更新。

    根據日媒報導,即將在4月推出小改款車型的Swift,在動力規格上,如無意外的話,Suzuki應也會擴大輕油電系統的應用範圍,進而在既有的1.0升渦輪、1.2升自然進氣動力設定之外,追加1.2升輕油電動力車型;同時同宗性能車型Swift Sport預計也將會在1.4升渦輪汽油引擎當中,額外追加48V輕油電動力架構,藉此改善該車款在油耗以及排污的各項表現。

    回到台灣國內,雖說受限於歐盟排放法規,台灣Suzuki早些時候已宣布停止Swift Sport的導入事宜,但一般常規Swift仍具備相當不俗的銷售潛力;為此外界一般也不排除,小改款Swift將會是台灣Suzuki下一批積極爭取導入的戰略車款。

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

    【其他文章推薦】

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

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

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

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

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

  • 最致命的七月! 日本上月逾300人死於氣候災難

    摘錄自2018年8月1日東森新聞台北報導

    日本西部本月初暴雨成災,引發多處爆發土石流,造成斯多人死傷。禍不單行的是,暴雨過後又有熱浪來襲,數以萬計的人因中暑入院,不少人因此死亡。

    更慘的是,最後還來了一個怪颱「雲雀」在日本拐來拐去,到處肆虐。 統計顯示,日本光是今年7月就有逾300人死於跟天氣相關的災難中,是該國近年最致命的一個月。

    日本迎來極高溫天氣,東京史上首度熱破40°C,多處地方打破歷來的高溫紀錄,至少已有116人死於這一波熱浪。 當局周二(31日)公布的數字顯示:7月第二周因中暑入院的人數比前一周飆升兩倍至將近萬人,第三周再飆升至2.2萬人,上周則稍為降低到1.37萬人。

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

    【其他文章推薦】

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

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

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

    ※超省錢租車方案

    FB行銷專家,教你從零開始的技巧

  • 研究:伊波拉疫情將隨二氧化碳濃度升高而擴大

    研究:伊波拉疫情將隨二氧化碳濃度升高而擴大

    環境資訊中心外電;姜唯 翻譯;林大利 審校;稿源:Carbon Brief

    根據發表在《自然通訊(Nature Communication)》的,當大氣中溫室氣體濃度升高,非洲伊波拉疫情爆發的威脅也將隨之增加。

    隨著氣溫上升,蝙蝠和其他會將病毒傳播給人類的動物可能遷移到新的區域,進而帶來疾病。

    新的模型顯示,如果人口繼續快速增加但發展緩慢且沒有相應的氣候行動,那麼到2070年,伊波拉疫情平均每10年就會爆發一次,今日的平均值是每17年一次。目前還不是疫區的西非和中非也可能受影響。

    該研究的結論是,在當前的經濟增長速度和高碳排放水準下,高風險區域的總面積可能擴大五分之一。在更高的碳排放水準下,甚至可能擴大1/3。

    作者們說,他們於2018年建立統計模型,成功預測了剛果民主共和國當前的疫情,目前伊波拉在當地已經奪走了兩千多條生命。

    因此,他們認為,這份研究當為非洲(包括過去認為未受影響的地區)針對性的伊波拉疫苗計畫和醫療基礎設施的部署奠定基礎。

    獅子山共和國境內努力對抗伊波拉病毒蔓延的村民。 (CC BY-NC-ND 2.0)

    伊波拉病毒於1976年首次被發現,2014年爆發疫情,造成西非成千上萬人喪生,在世界各地成為頭條新聞。

    一般認為這種傳染病是透過所謂的「溢出物感染」從蝙蝠和其他動物宿主傳播給人類的,是一種人畜共通傳染病。所有人類會感染的傳染病中,有2/3是人畜共通傳染病。

    伊波拉病毒一旦感染人類,就可經由直接接觸在人與人之間傳播。人類的症狀包括發燒、嘔吐,有時還包括內部和外部出血。平均死亡率約為50%。

    由於伊波拉疫情可能造成重大傷亡,科學家們必須了解下一次伊波拉疫情可能在何時何地爆發,以便分配醫療資源。

    但是,由於伊波拉自發現以來,確認的疫情暴發僅有23次,很難用傳統預測常見傳染病(如流感)的方法預測。

    伊波拉防疫措施。來源: 。(CC BY 2.0)

    倫敦大學學院的雷丁(David Redding)博士、瓊斯(Kate Jones)博士及其團隊沒有用以前的爆發資料進行研究,而是「由下而上」建立伊波拉爆發的風險模型。

    他們使用的資料包含許多因子,包括寄主分布、人口數、陸上交通、空中交通、以及土地利用類型。

    該分析的一個關鍵要素是氣候變遷,它既能影響當地社會經濟發展,也可以影響疾病傳播,而且正如雷丁所說,「在我們的模型中,大部分氣候的影響來自於為攜帶疾病的物種提供更好的條件,從而擴大了其地理分布範圍。」

    儘管究竟哪些動物能將伊波拉病毒傳給人類仍存在一些不確定性,最主要的嫌犯是大型狐蝠,而這種狐蝠常常被人類獵來吃。這些動物喜歡溫暖和潮濕的棲息地,隨著氣候變遷,高風險地區的棲息地還可能擴張。

    分析中還納入了其他可能是傳染途徑的動物,如猿類和麂羚。

    研究人員指出,從他們觀察到的結果看來,氣候的作用不如貧窮(後者與醫療保健的反應密切相關)和人口數。

    但他們也發現,溢出物感染隨著溫室氣體濃度的增加而增加。雷丁說,「在我們的模型中,負面影響隨著排放增加越來越明顯。」

    研究人員開發出一個可模擬西非流行的薩伊伊波拉病毒(Zaire Ebola virus, EBOV)人傳人和動物傳人的模型。

    科學家用圖示說明在不同排放情境下的伊波拉病毒擴散風險。來源:

    為了評估複雜的社會、經濟和氣候因素對非洲未來伊波拉病毒傳播的影響,研究團隊將氣候變遷情境中的代表濃度途徑(representative concentration pathways, RCPs)和共享社會經濟途徑(shared socio-economic pathways, SSPs)納入其模型。

    RCPs代表不同程度的氣候行動導致溫室氣體濃度不斷升高的情境。SSP代表各種社會經濟發展情境,涉及全球社會、人口統計和經濟學的不同狀況。

    接著,研究人員使用這些模型來預測到2070年非洲不同地區的伊波拉疫情風險變化。在大多數情境中,模擬結果顯示伊波拉發病率隨時間持續增加。

    但是,在永續發展和氣候變遷大規模緩解的情境,伊波拉疫情風險普遍下降。

    在現況條件下,模型預測,由溢出物感染引發的流行病大約每17年發生一次。流行病爆發在此定義為規模在1,500名患者以上的感染狀況。

    團隊使用現況條件進行了約1,500次年度模擬,發現其中約有5.8%發生了疫情爆發。接著使用不同的條件組合重複此過程。

    最大的增長發生在高排放、高人口增長和經濟發展緩慢的情況下(RCP6.0和SSP3),疫情幾乎每10年爆發一次。(論文的原始摘要寫道,在此情況下,疫情爆發的可能性比今日高出四倍,但是正確應是1.6倍。Carbon Brief與作者聯繫後確認了這一點。)

    在最樂觀的情境下(假定排放量適中且發展迅速,即RCP4.5和SSP1),頻率下降到大約每30年一次。

    模型也顯示,影響超過200萬人的「災難性疫情爆發」模式也很類似。目前這種事件預估每43年發生一次,但根據模擬,在高排放情境下,它們的發生頻率也將增加。

    模型還預測有爆發風險的區域會擴大。例如,在最樂觀的社會經濟和氣候情況下,有爆發風險的總面積與今天相比減少了近一半(分別是40萬平方公里和80萬平方公里)。

    相比之下,在低度氣候變遷緩解和中度發展(RCP6.0和SSP2)情境下,該面積增加了20.5%;在更極端的情況(RCP8.5和SSP3)下,該面積進一步增加了34%。

    值得注意的是,許多傳染病是透過環境傳播(例如水或土壤傳播),但伊波拉病毒是透過宿主之間的直接接觸傳播。這表示儘管蝙蝠和人類直接受到氣候變遷的影響,但病毒本身卻不太容易受氣候變遷影響。

    該論文的結論是,因應氣候變遷的全球性承諾也許有助降低伊波拉病例。但是對於這種推測不應太樂觀,因為「證據顯示不太可能發生全面性的改變」。

    「在中部和西部非洲減少貧困以及增加醫療資源,似乎是降低全球未來伊波拉疫情風險最現實的方法。」

    除了準確地找出已知有伊波拉疫情的地區外,該模型還確定了尼日、迦納和肯亞等國家都很可能受小規模溢出物感染和伊波拉疫情影響,儘管這些國家從來沒傳出伊波拉疫情過。

    Ebola epidemics will ‘increase with greenhouse gas concentrations’, study finds by Josh Gabbatiss

    The threat of Ebola outbreaks across Africa will increase as levels of greenhouse gases in the atmosphere rise, according to new research.

    With warming temperatures, bats and other animals that are thought to transmit the virus to humans are expected to move into new areas, bringing the disease with them. 

    The new modelling suggests that by 2070 epidemics could break out, on average, once every 10 years, if rapid population growth and slow development are accompanied by inaction on climate change. Under today’s conditions, the average is once every 17 years.

    According to the analysis, published in , changing conditions may also affect regions of West and Central Africa that are not currently considered at risk.

    The paper concludes that with current rates of economic growth and high emissions, the total epidemic-prone area could expand by a fifth. At even higher levels of emissions, it could expand by a third.

    The scientists behind the work say their modelling, which was undertaken in 2018, has already successfully predicted the currently underway in the Democratic Republic of Congo that has claimed more than 2,000 lives.

    With this in mind, they say the analysis should lay the groundwork for targeted Ebola vaccine programmes and healthcare infrastructure in Africa, including regions previously thought to be unaffected.

    Modelling everything

    First identified in 1976, Ebola around the world in 2014 when of epidemic proportions killed thousands of people in West Africa.

    The viral disease is thought to pass to humans from bats and other animal hosts in so-called “spillover events”. It is one of the many “zoonotic”, or animal-borne, diseases that make up of all human infectious diseases. 

    Once spread to humans, Ebola can be transmitted from person to person through direct contact. in humans include fever, vomiting and sometimes both internal and external bleeding. The average fatality rate is around 50%.

    Given its potential to inflict significant harm, it is vital that scientists understand when and where the next outbreak of Ebola is likely to strike so that medical resources can be directed accordingly.

    However, as there have only been around 23 confirmed outbreaks since the disease was discovered, traditional methods used to predict common infections, such as flu, are difficult.

    Instead of working from previous outbreak data, of , along with his colleague and their team, developed an outbreak risk model “from the bottom-up”. 

    They used data on a range of factors including host distribution, human population size, people’s movements by roads and air, and land use.

    , who leads the group at the and was not involved in the study, tells Carbon Brief that combining all these factors into a model is “extremely complex”. “Therefore, I am impressed by this work,” he says.

    One vital component of the analysis was climate change, which can influence disease spread both by affecting both local socioeconomic development and, as Redding tells Carbon Brief, the host species themselves:

    “In our model most of the climate effects are through better conditions for the disease-carrying species, thus increasing their native geographical range.”

    While there is still about precisely which animals pass Ebola on to humans, the prime suspects are large fruit bats that are often hunted . These creatures are known to prefer warm and wet habitats, which are expected to expand in the target regions as the climate changes.

    Other animals thought to provide alternative routes for infection, such as apes and duiker antelopes, were also considered in the analysis.

    The researchers note that climate played a less important role in their observed outcomes than poverty – which is closely tied with healthcare response – and human population size. 

    However, they also note that spillover events “increased with greenhouse gas concentrations”. Redding explains:

    “There is a positive association in our model results with increasingly more negative impact with higher emission scenarios.”

    Epidemic expansion

    The researchers developed a model that simulated animal-to-human and human-to-human transmission of Zaire Ebola virus (EBOV), the strain responsible for the West African epidemic.

    In order to gauge the impact of complex social, economic and climate factors on future Ebola transmission in Africa, the team then incorporated representative concentration pathways () and shared socio-economic pathways () into their modelling.

    RCPs broadly represent scenarios with ever-higher levels of greenhouse gases resulting from different levels of climate action. SSPs are for various socioeconomic development scenarios, involving different outcomes for global society, demographics and economics.

    (For more, see Carbon Brief’s recent on RCP8.5 and Carbon Brief’s SSP .)

    The researchers then used these models to project changes in Ebola risk across different African regions by the year 2070.

    Writing in their paper, they say their simulations suggest a “general, ongoing increase in Ebola incidence over time” for most scenarios.

    However, for scenarios involving sustainable development and extensive climate mitigation, there was a general decrease in Ebola risk (the chart below gives an idea of changing risk in different scenario combinations).

    Change in future risks of Ebola virus disease under different RCP and SSP scenarios. Each map represents mean change in “per grid cell probability” of an Ebola case from zero (yellow) to −0.06 (dark blue) and 0.06 (red), aggregated at a country level with data from the group’s model for 2070. Source: Redding et al. (2019)

    Under current conditions, the models predict an epidemic resulting from a spillover event will occur roughly once every 17 years. An epidemic was defined as an outbreak involving more than 1,500 patients.

    To arrive at this conclusion, the team ran around 1,500 yearly simulations using present day conditions and found that epidemics occurred in approximately 5.8% of them. This process was then repeated using different sets of conditions.

    The greatest increase occurs in a scenario with high emissions, high population growth and slow economic development (RCP6.0 and SSP3), with epidemics expected to occur nearly once every 10 years.

    (The likelihood of epidemics occurring under these conditions compared to present day was incorrectly described as four times more likely, instead of 1.6 times more likely, in the paper’s original abstract. The authors confirmed this after Carbon Brief contacted them about the discrepancy.)

    Under the most optimistic of the scenarios they used – which assumes moderate emissions and high development (RCP4.5 and SSP1) – the occurrence drops to roughly once every 30 years.

    A similar pattern is expected to play out for “catastrophic epidemics” affecting more than two million people. These events are currently predicted to take place once every 43 years, but the modelling suggests they will increase in frequency under high-emissions scenarios.

    The models also predict an expansion in the area at risk from outbreaks. For example, under the most optimistic socioeconomic and climate scenario, the total area where epidemics could start decreased by nearly half compared to present day (0.4m square kilometres, km2, compared to 0.8m km2).

    In comparison, in a scenario involving low climate mitigation and “middle of the road” development (RCP6.0 and SSP2), this area increased by 20.5%, Under a more extreme scenario (RCP8.5 and SSP3) this increased further, by 34%.

    Disease and climate

    While the links between climate and Ebola, Redding and his co-authors think this is the first attempt to model future transmission of the disease that takes climate change into account.

    Baylis says there has been extensive work exploring direct links between changing climate and the spread of disease – for example, in the Kenyan highlands and malaria risk. 

    However, while work from his own group has suggested of infectious diseases are susceptible to climate, he says identifying these links can be challenging:

    “Attribution is difficult, because we are really saying that climate change increases the probability of an event, but extreme events are expected even without climate change.”

    It is worth noting that while many infectious diseases are transmitted via the environment (by way of water or soil, for example), Ebola moves via direct contact between hosts. This means while bats and humans are affected directly by the changing climate, the virus itself is less susceptible to a changing climate.

    The paper concludes that global commitments to tackle climate change may drive down Ebola cases. However, it is not optimistic about this outcome, noting “evidence suggests a wholesale change is unlikely”:

    “Efforts to decrease poverty in Central and Western Africa with a concomitant increase in healthcare resources, therefore, would appear to be the most realistic approach to reducing future Ebola virus disease risk globally.”

    Future response

    Besides accurately identifying the known endemic area for Ebola, the modelling also identifies countries such as Nigeria, Ghana and Kenya as vulnerable to both small spillovers and epidemics of Ebola, despite never having been the source of such outbreaks before.

    The team says their approach “somewhat contradict[s] analyses based on current case data”.

    According to Baylis, the team’s validation of past outbreaks using the new approach increases confidence in future predictions, but notes the models are still “likely constrained by the quality of our knowledge of Ebola hosts, which is not high”.

    Besides identifying a “much larger” area within Africa that is vulnerable to spillover events, the team also incorporated information about airline routes and concluded that China, Russia, India, the US and many European countries were at risk of importing the disease.

    According to Redding, their work “acts as a call” for both a better understanding of where Ebola outbreaks could hit, plus the need for cooperation between wealthier and poorer countries to improve healthcare resources in preparation. He concludes:

    “Such an approach is a no-lose situation as better containment facilities and barrier nursing, for example, could protect nations and their neighbours against many different future disease outbreaks, not just Ebola.”

    ※ 全文及圖片詳見:()

    ※ 論文資料:Redding, D. et al. (2019) Impacts of environmental and socio-economic factors on emergence and epidemic potential of Ebola in Africa, Nature Communications,

    作者

    如果有一件事是重要的,如果能為孩子實現一個願望,那就是人類與大自然和諧共存。

    於特有生物研究保育中心服務,小鳥和棲地是主要的研究對象。是龜毛的讀者,認為龜毛是探索世界的美德。

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

    【其他文章推薦】

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

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

    ※超省錢租車方案

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

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

  • 用剛果童工挖鈷致死或殘 5科技巨頭挨告

    摘錄自2019年12月17日聯合報報導

    特斯拉、蘋果、微軟、戴爾、Google母公司字母(Alphabet)以共謀罪名被告上法庭。這是科技業首次因其鈷來源,共同面臨法律訴訟。

    代表剛果民主共和國14個家庭擔任原告的美國人權組織「國際權利倡議」(International Rights Advocates)15日提告五家全球大型科技公司,指強迫勞動的體系導致這些家庭的小孩死亡或重傷,而五家科技業者是這個體系的一部分。

    這起訴訟說,案件裡的兒童,最小的才6歲,因為出身赤貧家庭,不得不休學到嘉能可的礦坑挖鈷。他們每周要工作六天,有些人領的日薪低到只有1.5美元(約台幣45元)。

    鈷是製造科技產品內部可重複使用鋰電池的必要材料。全球一半以上的鈷產自剛果民主共和國。根據歐盟執委會2018年的一份研究,未來10年全球鈷需求料將每年增加7%到13%。原告主張,挨告的科技業者全都有能力徹底整頓旗下鈷供應鏈,以確保更安全的工作條件。

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

    【其他文章推薦】

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

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※回頭車貨運收費標準

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

    ※超省錢租車方案

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

  • 【K8S學習筆記】初識K8S 及架構組件

    【K8S學習筆記】初識K8S 及架構組件

    K8S是什麼?發展歷史

    Kubernetes (簡稱 k8s)是 Google 在2014年開源的,對容器生命周期管理的開源平台,致力於對容器集群提供易於管理、高可用、彈性負載與故障轉移的能力,提高服務運維自動化的能力。

    最初,Google 開發了一個叫 Borg 的系統(現在命名為Omega)來調度據說有20多億個容器和工作負載。在積累了 10 余年經驗后,Google 決定重寫這個容器管理系統,並將其命名為 Kubernetes 貢獻給開源社區,讓全世界都能因此受益。

    自從開源以來,K8S迅速獲得開源社區的追捧,包括RedHat、VMware、Canonical在內的有很大影響力公司加入到開發與推廣的陣營。

    當微服務的概念的落地實踐開始,微服務就與容器緊緊地綁在了一起,可以說K8s的成功離不開微服務與容器。

    2017年是容器生態發展歷史中具有里程碑意義的一年。

    在這一年,長期作為Docker競爭對手的RKT容器一派的領導者CoreOS宣布放棄自己的容器管理系統Fleet,未來將會把所有容器管理的功能移至Kubernetes之上去實現。

    在這一年,容器管理領域的獨角獸Rancher Labs宣布放棄其內置了數年的容器管理系統Cattle,提出了“All-in-Kubernetes”戰略,從2.0版本開始把1.x版本能夠支持多種容器管理工具的Rancher,“升級”為只支持Kubernetes一種容器管理系統。

    在這一年,Kubernetes的主要競爭者Apache Mesos在9月正式宣布了“Kubernetes on Mesos”集成計劃,由競爭關係轉為對Kubernetes提供支持,使其能夠與Mesos的其他一級框架(如HDFS、Spark 和Chronos,等等)進行集群資源動態共享、分配與隔離。

    在這一年,Kubernetes的最大競爭者Docker Swarm的母公司Docker,終於在10月被迫宣布Docker要同時支持Swarm與Kubernetes兩套容器管理系統,事實上承認了Kubernetes的統治地位。這場已經持續了三、四年時間,以Docker Swarm、Apache Mesos與Kubernetes為主要競爭者的“容器戰爭”終於有了明確的結果。

    時至今日,K8S 已經是發展最快、市場佔有率最高的容器編排系統,是業界標杆。

    小結:Kubernetes是Google公司2014年開源的容器編排產品,經過多年的發展,已經成為容器編排領域的佼佼者,擁有最廣大的用戶群體

    應用部署容器化的發展歷程

    要說K8S的作用,得先從容器的發展與優勢講起,大致可分為 傳統部署時代、虛擬化部署時代、容器部署時代

    傳統部署時代: 早期,在物理服務器上運行應用程序。無法為物理服務器中的應用程序定義資源邊界,這會導致資源分配困難與資源浪費的問題。例如,如果在物理服務器上運行多個應用程序,則可能會出現一個應用程序佔用大部分資源的情況,結果可能導致其他應用程序的性能下降。一種解決方案是在不同的物理服務器上運行每個應用程序,但是由於資源利用不足而無法擴展,並且組織維護許多物理服務器的成本很高

    虛擬化部署時代: 作為解決方案,引入了虛擬化功能,它允許您在單個物理服務器的 CPU 上運行多個虛擬機(VM)。虛擬化功能允許應用程序在 VM 之間隔離,並提供安全級別,因為一個應用程序的信息不能被另一應用程序自由地訪問。

    因為虛擬化可以輕鬆地添加或更新應用程序、降低硬件成本等等,所以虛擬化可以更好地利用物理服務器中的資源,並可以實現更好的可伸縮性。

    每個 VM 是一台完整的計算機,在虛擬化硬件之上運行所有組件,包括其自己的操作系統,這勢必也會造成資源的浪費、性能的下降

    容器部署時代: 容器類似於 VM,但是它們具有輕量級的隔離屬性,可以在應用程序之間共享操作系統(OS)。因此,容器被認為是輕量級的。容器與 VM 類似,具有自己的文件系統、CPU、內存、進程空間等。由於它們與基礎架構分離,因此可以跨雲和 OS 分發進行移植

    容器因具有許多優勢而變得流行起來。下面列出了容器的一些好處

    • 敏捷應用程序的創建和部署:與使用 VM 鏡像相比,提高了容器鏡像創建的簡便性和效率。
    • 持續開發、集成和部署:通過快速簡單的回滾(由於鏡像不可變性),提供可靠且頻繁的容器鏡像構建和部署。
    • 關注開發與運維的分離:在構建/發布時而不是在部署時創建應用程序容器鏡像,從而將應用程序與基礎架構分離。
    • 可觀察性:不僅可以显示操作系統級別的信息和指標,還可以显示應用程序的運行狀況和其他指標信號。
    • 跨開發、測試和生產的環境一致性:在便攜式計算機上與在雲中相同地運行。
    • 雲和操作系統分發的可移植性:可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方運行。
    • 以應用程序為中心的管理:提高抽象級別,從在虛擬硬件上運行 OS 到使用邏輯資源在 OS 上運行應用程序。
    • 鬆散耦合、分佈式、彈性、解放的微服務:應用程序被分解成較小的獨立部分,並且可以動態部署和管理 – 而不是在一台大型單機上整體運行。
    • 資源隔離:可預測的應用程序性能。
    • 資源利用:高效率和高密度。

    小結:相對於傳統物理機部署方式,虛擬機部署將資源更好的隔離開來,使資源分配與隔離的問題解決,提高了資源使用率,但是由於其虛擬了硬件與OS,會浪費不必要的資源;容器部署繼承了虛擬機部署的資源隔離優勢的同時,使用共享宿主機的硬件與OS的方式,資源消耗更少,由於與基礎架構進行了分離,可以做到良好的移植性

    為什麼需要 Kubernetes,它能做什麼?

    容器是打包和運行應用程序的好方式。在生產環境中,如果一個容器發生故障,則啟動另一個容器。如此處理會不會更簡單?

    K8s就是這麼做的!K8s 為您提供了一個可彈性運行分佈式系統的框架,能滿足您的擴展要求、故障轉移、部署模式等。

    Kubernetes 為您提供:

    • 服務發現和負載均衡
      Kubernetes 可以使用 DNS 名稱或自己的 IP 地址公開容器,如果到容器的流量很大,Kubernetes 可以負載均衡並分配網絡流量,從而使部署穩定。

    • 存儲編排
      Kubernetes 允許您自動掛載您選擇的存儲系統,例如本地存儲、公共雲提供商等。

    • 自動部署和回滾
      您可以使用 Kubernetes 描述已部署容器的所需狀態,它可以以受控的速率將實際狀態更改為所需狀態。例如,您可以自動化 Kubernetes 來為您的部署創建新容器,刪除現有容器並將它們的所有資源用於新容器。

    • 自動二進制打包
      Kubernetes 允許您指定每個容器所需 CPU 和內存(RAM)。當容器指定了資源請求時,Kubernetes 可以做出更好的決策來管理容器的資源。

    • 自我修復
      Kubernetes 重新啟動失敗的容器、替換容器、殺死不響應用戶定義的運行狀況檢查的容器,並且在準備好服務之前不將其通告給客戶端。

    • 密鑰與配置管理
      Kubernetes 允許您存儲和管理敏感信息,例如密碼、OAuth 令牌和 ssh 密鑰。您可以在不重建容器鏡像的情況下部署和更新密鑰和應用程序配置,也無需在堆棧配置中暴露密鑰。

    小結:K8S 提供了服務發現和負載均衡、存儲編排、自動部署和回滾、自動二進制打包、自我修復、密鑰與配置管理等功能,能滿足您的擴展要求、故障轉移、部署模式等需求

    擴展
    1、有微服務實踐的讀者可能會發現,微服務組件中的服務發現、負載均衡、網關等功能在K8s體系中都有對應的實現,那麼是不是我就可以不使用其他微服務的體系而直接擁抱K8s呢?
    答案是可以的。但有一點限制就是開發人員要學習K8s,偏向DevOps了。
    2、既然K8s提供了微服務所需的基礎組件實現,但我可以不用么?
    答案也是可行的。K8s的組件插拔能力允許你這麼做,這樣一來開發測試環境使用本地部署註冊中心等組件,開發人員就無需關心K8s了,只需要理解所用微服務框架本身,如Spring Cloud等。

    Kubernetes 不是什麼

    Kubernetes 不是傳統的、包羅萬象的 PaaS(平台即服務)系統。它只提供了 PaaS 產品共有的一些普遍適用的功能,例如部署、擴展、負載均衡、日誌記錄和監視。但是,Kubernetes 不是單一的,默認解決方案是可選和可插拔的。Kubernetes 提供了構建開發人員平台的基礎,但是在重要的地方保留了用戶的選擇和靈活性。

    Kubernetes:

    • 不限制支持的應用程序類型。Kubernetes 旨在支持極其多種多樣的工作負載,包括無狀態、有狀態和數據處理工作負載。如果應用程序可以在容器中運行,那麼它應該可以在 Kubernetes 上很好地運行。

    • 不部署源代碼,也不構建您的應用程序。持續集成(CI)、交付和部署(CI/CD)工作流取決於組織的文化和偏好以及技術要求。

    • 不提供應用程序級別的服務作為內置服務,例如中間件(例如,消息中間件)、數據處理框架(例如,Spark)、數據庫(例如,mysql)、緩存、集群存儲系統(例如,Ceph)。這樣的組件可以在 Kubernetes 上運行,並且/或者可以由運行在 Kubernetes 上的應用程序通過可移植機制(例如,開放服務代理)來訪問。

    • 不指定日誌記錄、監視或警報解決方案。它提供了一些集成作為概念證明,並提供了收集和導出指標的機制。

    • 不提供或不要求配置語言/系統(例如 jsonnet),它提供了聲明性 API,該聲明性 API 可以由任意形式的聲明性規範所構成。

    • 不提供也不採用任何全面的機器配置、維護、管理或自我修復系統

    • 此外,Kubernetes 不僅僅是一個編排系統,實際上它消除了編排的需要。編排的技術定義是執行已定義的工作流程:首先執行 A,然後執行 B,再執行 C。相比之下,Kubernetes 包含一組獨立的、可組合的控制過程,這些過程連續地將當前狀態驅動到所提供的所需狀態。從 A 到 C 的方式無關緊要,也不需要集中控制,這使得系統更易於使用且功能更強大、健壯、彈性和可擴展性。

    小結:K8S 提供了基礎的容器編排平台,但並不是大而全地將所有可能的功能都直接集成進來,而是做成可插拔的形式,可以做到因地適宜地組織與管理集群,擁有很高的靈活性。

    Kubernetes 架構與組件

    K8s的架構如上圖,左邊虛線框的部分稱為 控制平面(Control Plane),右側為 集群節點(Nodes)

    控制平面所在的主機稱為 Master 節點,其餘稱為 Nodes 執行節點

    簡單按這兩種角色來講,Master節點負責發號施令(下發命令、監控節點與容器狀態),而 Nodes 節點負責幹活

    控制平面(Control Plane)組件

    控制平面的組件對集群做出全局決策(比如調度),以及檢測和響應集群事件

    控制平面組件可以在集群中的任何節點上運行。簡單起見,通常會將控制平台配置在一台主機上,也可以配置高可用形式。

    下邊我們介紹下 控制平面中的幾大組件:

    • kube-apiserver:Master節點上負責提供 Kubernetes API 服務的組件;它是 Kubernetes 控制面的前端,由它來接收來自 CLI 與 UI 的指令
    • etcd:是兼具一致性和高可用性的鍵值數據庫,可以作為保存 Kubernetes 所有集群數據的後台數據庫。
    • kube-scheduler:Master節點上的組件,該組件監視那些新創建的未指定運行節點的 Pod,並選擇節點讓 Pod 在上面運行。
    • kube-controller-manager:控制器通過 apiserver 監控集群的公共狀態,並致力於將當前狀態轉變為期望的狀態。從邏輯上講,每個控制器都是一個單獨的進程,但是為了降低複雜性,它們都被編譯到同一個可執行文件,並在一個進程中運行。包含以下幾種控制器:
      • 節點控制器(Node Controller): 負責在節點出現故障時進行通知和響應。
      • 副本控制器(Replication Controller): 負責為系統中的每個副本控制器對象維護正確數量的 Pod。
      • 端點控制器(Endpoints Controller): 填充端點(Endpoints)對象(即加入 Service 與 Pod)。
      • 服務帳戶和令牌控制器(Service Account & Token Controllers): 為新的命名空間創建默認帳戶和 API 訪問令牌
    • cloud-controller-manager:雲控制器管理器負責與基礎雲提供商交互,以下控制器具有雲提供商依賴性:
      • 節點控制器(Node Controller): 用於檢查雲提供商以確定節點是否在雲中停止響應后被刪除
      • 路由控制器(Route Controller): 用於在底層雲基礎架構中設置路由
      • 服務控制器(Service Controller): 用於創建、更新和刪除雲提供商負載均衡器
      • 數據卷控制器(Volume Controller): 用於創建、附加和裝載卷、並與雲提供商進行交互以編排卷

    節點(Node) 組件

    節點組件在每個節點上運行,維護運行的 Pod 並提供 Kubernetes 運行環境

    節點組件包含兩大組件:

    • kubelet:一個在集群中每個節點上運行的代理。它保證容器都運行在 Pod 中。

      kubelet 接收一組通過各類機制提供給它的 PodSpecs,確保這些 PodSpecs 中描述的容器處於運行狀態且健康。kubelet 不會管理不是由 Kubernetes 創建的容器。

    • kube-proxy:是集群中每個節點上運行的網絡代理,實現 Kubernetes Service 概念的一部分。

      kube-proxy 維護節點上的網絡規則。這些網絡規則允許從集群內部或外部的網絡會話與 Pod 進行網絡通信。

      如果操作系統提供了數據包過濾層並可用的話,kube-proxy會通過它來實現網絡規則。否則,kube-proxy 僅轉發流量本身

    • 容器運行環境(Container Runtime):容器運行環境是負責運行容器的軟件。K8s支持多種容器運行環境:Docker、containerd、cri-o、rklet 以及任何實現K8s容器運行環境接口的技術。

    插件(Addons)

    • DNS:所有 Kubernetes 集群都應具有 DNS。集群 DNS 還是一個 DNS 服務器,它為 Kubernetes 服務提供 DNS 記錄。

    • 用戶界面(Dashboard):Kubernetes 集群基於 Web 的 UI。它使用戶可以管理集群中運行的應用程序以及集群本身並進行故障排除。

    Dashboard 是 Kubernetes 集群的通用基於 Web 的 UI。它使用戶可以管理集群中運行的應用程序以及集群本身並進行故障排除。

    • 容器資源監控:將關於容器的一些常見的時間序列度量值保存到一個集中的數據庫中,並提供用於瀏覽這些數據的界面。

    • 集群層面日誌:負責將容器的日誌數據保存到一個集中的日誌存儲中,該存儲能夠提供搜索和瀏覽接口。

    小結:K8s架構分為控制平台位於的Master節點與執行節點Node

    控制平台包含:

  • kube-apiserver(訪問入口,接收命令)
  • etcd(KV數據庫,保存集群狀態與數據)
  • kube-scheduler(監控節點狀態,調度容器部署)
  • kube-controller-manager(監控集群狀態,控制節點、副本、端點、賬戶與令牌)
  • cloud-controller-manager(控制與雲交互的節點、路由、服務、數據卷)
  • 執行節點包含:

  • kubelet(監控與實際操作容器)
  • kube-proxy(每個節點上運行的網絡代理,維護網絡轉發規則,實現了Service)
  • 容器運行時環境CRI(支持多種實現K8s CRI的容器技術)
  • 本文總結

    Kubernetes 作為容器編排的領航者,將容器化的優勢發揮得淋漓盡致,排除了容器難於管理的問題。

    按角色來看,K8s可以分為兩部分,控制平面與執行節點,控制平台通過一系列接收指令、監控、部署調度等功能的組件組成,最主要的有kube-apiserver、etcd、kube-scheduler、kube-controller-manager;執行節點包含負責監控與具體幹活的kubelet和維護網絡規則的kube-proxy

    參考文章

    • https://kubernetes.io/docs/concepts/overview/components/

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

    【其他文章推薦】

    ※帶您來了解什麼是 USB CONNECTOR  ?

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

    ※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!

    ※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

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

  • Java多線程與併發基礎面試題

    CS-LogN思維導圖:記錄專業基礎 面試題
    開源地址:https://github.com/FISHers6/CS-LogN

    多線程與併發基礎

    實現多線程

    面試題1:有幾種實現線程的方法,分別是什麼

    • 1.繼承Thread類,啟動線程的唯一方法就是通過 Thread 類的 start()實例方法,start()方法是一個 native 方法,它將啟動一個新線程去執行 run()方法

    • 2.實現 Runnable 接口,重寫run()函數,作為參數放到Thread類構造函數中作為target屬性,運行start()方法

    • 線程池創建線程、Callable本質還是使Runnable創建,Callable是父輩類繼承了Runnable,線程池需傳入參數

    面試題2:實現Runnable方法好,還是繼承Thread類好

    • 實現Runnable接口更好

      • 1.單一繼承原則,如果繼承了Thread,就不能繼承其它類了,限制了可擴展性
      • 2.Thread類每次只能創建一個獨立的線程,損耗大,而Runnable能利用線程池工具來創建線程
      • 3.從代碼架構上看,run內容應該與Trhead代碼解耦

    面試題3:一個線程兩次調用start方法會出現什麼情況(考察源碼)

    • 第二次會出現異常,從start源碼上和線程生命周期上分析,一個線程start后,
      改變了threadState狀態字;而第二次再start每次會先檢查這個狀態不是0就報異常

    面試題4:既然start方法會調用run方法,為什麼我們還是要用start方法,而不是直接調用run方法呢(考察源碼)

    • 因為start后線程才會經過完整的線程生命周期,start調用native start0,虛擬機執startThread,thread_entry入口中調用Thread的run,

    面試題5:start和run有什麼區別

    • run()方法:只是普通的方法,調用run普通方法,可以重複多次調用
    • start()方法,會啟動一個線程,使得虛擬機去調用Runnable對象的run()方法,不能多次啟動同一個線程

    面試題6:start方法如何調用run方法的(考察源碼和JVM)

    • start方法調用native start0,JVM虛擬機執行startThread,在thread_entry中調用Thread的run方法

    面試題7:如何正確停止線程

    • 使用interrupt中斷通知,而不是強制,中斷通知後會讓被停止線程去決定何時停止,即把主動權交給需要被中斷的線程

    線程的生命周期

    面試題1:Java線程有哪幾種狀態 說說生命周期

    • 六種生命狀態(若time_waiting也算一種)

      • New,已創建但還尚未啟動的新線程
      • Runable,可運行狀態;對應操作系統的兩種狀態“就緒態” 和 “運行態”(分配到CPU)
      • Blocked,阻塞狀態;請求synchronized鎖未分配到時阻塞,直到獲取到monitor鎖再進入Runnable
      • Waiting,等待狀態
      • Timed waiting,限期等待
      • Terminated終止狀態
    • 線程的生命周期 狀態轉換圖

    Thread和Object類中

    與線程相關的重要方法

    面試題1:實現兩個線程交替打印奇數偶數

    面試題2:手寫生產者消費者設計模式,為什麼用該模式

    • 主要是為了解耦,匹配不同的能力

    面試題3:wait后發生了什麼,為什麼需要在同步代碼內才能使用

    • 從jvm的源碼實現上看,wait后,線程讓出佔有的cpu並釋放同步資源鎖;把自己加入到等待池,以後不會再主動參与cpu的競爭,除非被其它notify命中
    • 為了確保線程安全;另外wait會釋放資源,所以肯定要先拿到這個鎖,能進入同步代碼塊已經拿到了鎖

    面試題4:為什麼線程通信的方法wait,notify和notifyAll放在Object類,而sleep定義在Thread類里 (考察對象鎖)

    • 與對象的鎖有關,對象鎖綁定在對象的對象頭中,且放在Object里,使每個線程都可以持有多個對象的鎖

    面試題5:wait方法是屬於Object對象的,那調用Thread.wait會怎麼樣

    • 線程死的時候會自己notifyAll,釋放掉所有的持有自己對象的鎖。這個機制是實現很多同步方法的基礎。如果調用Thrad.wait,干擾了我們設計的同步業務流程

    面試題6:如何選擇notify還是notifyAll

    • 優先選用notifyAll,喚醒所有線程;除非業務需要每次只喚醒一個線程的

    面試題7:notfiy后發生的操作,notifyAll之後所有的線程都會再次搶奪鎖,如果某線程搶奪失敗怎麼辦?

    • notify后,讓waiterSet等待池中的一個線程與entry_List鎖池一級活躍線程一起競爭CPU
    • 搶奪鎖失敗後會繼續待在原鎖池或原等待池,等待競爭CPU的調度

    面試題8:sleep方法與notify/wait方法的異同點

    • 相同點:線程都會進入waiting狀態,都可以響應中斷
    • 不同點:1.所屬類不同;2.wait/notify必須用在同步方法中,且會釋放鎖;3.sleep可以指定時間

    面試題9:join方法後父線程進入什麼狀態

    • waiting狀態,join內部調用wait,子線程結束后自動調用notifyAll喚醒(jvm:exit函數)

    線程安全與性能

    面試題1:守護線程和普通線程的區別

    • 守護線程是服務於普通線程的,並且不會影響到jvm的退出

    面試題2:什麼是線程安全

    • 不管業務中遇到怎樣的多個線程訪問某對象或某方法的情況,而在編程這個業務邏輯的時候,都不需要再額外做任何額外的處理(也就是可以像單線程編程一樣),程序也可以正常運行(不會因為多線程而出錯),就可以稱為線程安全

    面試題3:有哪些線程不安全的情況,什麼原因導致的

    • 1.數據爭用、同時操作,如數據讀寫由於同時寫,非原子性操作導致運行結果錯誤,a++
    • 2.存在競爭,順序不當,如死鎖、活鎖、飢餓

    面試題4:什麼是多線程的上下文切換,及導致的後果

    • 進程線程切換要保存所需要的CPU運行環境,如寄存器、棧、全局變量等資源
    • 在頻繁的io以及搶鎖的時候,會導緻密集的上下文切換,多線程切換時,由於緩存和上下文的切換會帶來性能問題

    面試題5:多線程導致的開銷有哪些

    • 1.上下文切換開銷,如保存緩存(cache、快表等)的開銷

    • 2.同步協作的開銷(java內存模型)

      • 為了數據的正確性,同步手段往往會使用禁止編譯器優化(如指令重排序優化、鎖粗化等),性能變差
      • 使CPU內的緩存失效(比如volatile可見性讓自己線程的緩存失效后,必須使用主存來查看數據)

    Java內存模型

    面試題1:Java的代碼如何一步步轉化,最終被CPU執行的

      1. 最開始,我們編寫的Java代碼,是*.java文件
    1. 在編譯(javac命令)后,從剛才的.java文件會變出一個新的Java字節碼文件.class
    2. JVM會執行剛才生成的字節碼文件(*.class),並把字節碼文件轉化為機器指令
    3. 機器指令可以直接在CPU上執運行,也就是最終的程序執行
    • JVM實現會帶來不同的“翻譯”,不同的CPU平台的機器指令又千差萬別,無法保證併發安全的效果一致

    面試題2:單例模式的作用和適用場景

    • 單例模式:只獲取一次資源,全程序通用,節省內存和計算;保證多線程計算結果正確;方便管理;
      比如日期工具類只需要一個實例就可以,無需多個示例

    面試題3:單例模式的寫法,考察(重排序、單例和高併發的關係)

    • 餓漢式(靜態常量、靜態代碼塊)

      • 原理1:static靜態常量在類加載的時候就初始化完成了,且由jvm保證線程安全,保證了變量唯一
      • 原理2:靜態代碼塊中實例化和靜態常量類似;放在靜態代碼塊里初始化,類加載時完成;
      • 特徵:簡單,但沒有懶加載(需要時再加載)
    • 懶漢式(加synchronized鎖)

      • 對初始化的方法加synchronized鎖達到線程安全的目的,但效率低,多線程下變成了同步
      • 懶漢式取名:用到的時候才去加載
    • 雙重檢查

      • 代碼實現

        • 屬性加volatile,兩次if判斷NULL值,第二次前加類鎖
      • 優點

        • 線程安全;延遲加載;效率高
      • 為什麼用雙重而不用單層

        • 從線程安全方面、效率方面講
    • 靜態內部類

      • 需要理解靜態內部類的優點,懶漢式加載,jvm加載順序
    • 枚舉

      • 代碼實現簡單

        • public enum Singleton{
          INSTANCE;
          public void method(){}
          }
      • 保證了線程安全

        • 枚舉是一個特殊的類,經過反編譯查看,枚舉最終被編譯成一個final的類,繼承了枚舉父類。各個實例通過static定義,本質就是一個靜態的對象,所有第一次使用的時候採取加載(懶加載)
      • 避免反序列化破壞單例

        • 避免了:比如用反射就繞過了構造方法,反序列化出多個實例

    面試題4:單例模式各種寫法分別適用的場合

    • 1.最好的方法是枚舉,因枚舉被編譯成final類,用static定義靜態對象,懶加載。既保證了線程安全又避免了反序列化破壞單例
    • 2.如果程序一開始要加載的資源太多,考慮到啟動速度,就應該使用懶加載
    • 3.如果是對象的創建需要配置文件(一開始要加載其它資源),就不適合用餓漢式

    面試題5:餓漢式單例的缺點

    • 沒有懶加載(初始化時全部加載出),初始化開銷大

    面試題6:懶漢式單例的缺點

    • 雖然用到的時候才去加載,但是由於加鎖,性能低

    面試題7:單例模式的雙重檢查寫法為什麼要用double-check

    • 從代碼實現出發,保證線程安全、延遲加載效率高

    面試題8:為什麼雙重檢查要用volatile

    • 1.保證instance的可見性

      • 類初始化分成3條指令,重排序帶來NPE空虛指針問題,加volatile防止重排序
    • 2.防止初始化指令重排序

    面試題9:講一講什麼是Java的內存模型

    • 1.是一組規範,需要JVM實現遵守這個規範,以便實現安全的多線程程序
      2.volatile、synchronized、Lock等同步工具和關鍵字實現原理都用到了JMM
      3.重排序、內存可見性、原子性

    面試題10:什麼是happens-before,規則有哪些

    • 解決可見性問題的:在時間上,動作A發生在動作B之前,B保證能看見A,這就是happens-before

    • 規則

      • 1 單線程按代碼順序規則;2 鎖操作(synchronized和Lock);3volatile變量;4.JUC工具類的Happens-Before原則
      • 5.線程啟動時子線程啟動前能看到主線程run的所有內容;6.線程join主線程一定要等待子線程完成后再去做後面操作
      • 7.傳遞性 8.中斷檢測 9.對象構造方法的最後一行指令 happens-before 於 finalize() 方法的第一行指令

    面試題11:講一講volatile關鍵字

    • volatile是一種同步機制,比synchronized或者Lock相關類更輕量,因為使用volatile並不會發生上下文切換等開銷很大的行為。而加鎖時對象鎖會阻塞開銷大。
    • 可見性,如果一個變量別修飾成volatile,那麼JVM就知道了這個變量可能會被併發修改;
    • 不能保證原子性

    面試題12:volatile的適用場合及作用

    • 作用

      • 1.保證可見性 2.禁止指令重排序(單例雙重鎖時)
    • 適合場景

      • 適用場合1:boolean flag,布爾具有原子性,可再由volatile保證其可見性
      • 適用場合2:作為刷新之前變量的觸發器
      • 但不適合非原子性操作如:a++等

    面試題13:volatile和synchronized的異同

    • 1 性能開銷方面: 鎖開銷更大,volatile無加鎖阻塞開銷
      2 作用方面:volatile只能保證可見性,鎖既能保證可見性,又能保證原子性

    面試題14:什麼是內存可見性問題,為什麼存在

    • 多線程下,一個線程修改共享數據后,其它線程能否感知到修改了數據的線程的變化
    • CPU有多級緩存,導致讀的數據過期,各處理機有獨自的緩存未及時更新時,與主存內容不一致

    面試題15:主內存和本地內存的關係是什麼

    • Java 作為高級語言,屏蔽了CPU cache等底層細節,用 JMM 定義了一套讀寫內存數據的規範,雖然我們不再需要關心一級緩存和二級緩存的問題,但是,JMM 抽象了主內存和本地內存的概念。
    • 線程擁有自己的本地內存,並共享主內存的數據;線程讀寫共享數據也是通過本地內存交換的,所以才導致了可見性問題。

    面試題16:什麼是原子操作,Java的原子操作有哪些

    • 原子操作

      • 一系列的操作,要麼全部執行成功,要麼全部不執行,不會出現執行一半的情況,是不可分割的。
    • 1)除long和double之外的基本類型(int, byte, boolean, short, char, float)的”賦值操作”

    • 2)所有”引用reference的賦值操作”,不管是 32 位的機器還是 64 位的機器

    • 3)java.concurrent.Atomic.* 包中所有類的原子操作

    面試題17:long 和 double 的原子性你了解嗎

    • 在32位上的JVM上,long 和 double的操作不是原子的,但是在64位的JVM上是原子的。
    • 在32位機器上一次只能讀寫32位;而浮點數、long型有8字節64位;要分高32位和低32位兩條指令分開寫入,類似彙編語言浮點數乘法分高低位寄存器;64位不用分兩次讀寫了

    面試題18:生成對象的過程是不是原子操作

    • 不是,對象生成會生成分配空間、初始化、賦值,三條指令,有可能會被重排序,導致空指針

    面試題19:區分JVM內存結構、Java內存模型 、Java對象模型

    • Java內存模型,和Java的併發編程有關

      • 詳見面試題9
    • JVM內存結構,和Java虛擬機的運行時區域(堆棧)有關

      • 堆區、方法區(存放常量池 引用 類信息)
        棧區、本地方法棧、程序計數器

    • Java對象模型,和Java對象在虛擬機中的表現形式有關

      • 是Java對象自身的存儲模型,在方法區中Kclass類信息(虛函數表),在堆中存放new實例,在線程棧中存放引用,OOP-Klass Model

    面試題20:什麼是重排序

    • 指令實際執行順序和代碼在java文件中的順序不一致
    • 重排序的好處:提高處理速度,包括編譯器優化、指令重排序(局部性原理)

    死鎖

    面試題1:寫一個必然死鎖的例子

    • synchronized嵌套,構成請求循環

    面試題2:生產中什麼場景下會發生死鎖

    • 併發中多線程互不相讓:當兩個(或更多)線程(或進程)相互持有對方所需要的資源,又不主動釋放,導致所有人都無法繼續前進,導致程序陷入無盡的阻塞,這就是死鎖。

    面試題3:發生死鎖必須滿足哪些條件

    • 1.互斥
    • 2.請求和保持
    • 3.不可剝奪
    • 4.存儲循環等待鏈

    面試題4:如何用工具定位死鎖

    • 1.jstack命令在程序發生死鎖后,進行堆棧分析出死鎖線程
    • 2.ThreadMXbean 程序運行中發現死鎖,一旦發現死鎖可以讓用戶去打日誌

    面試題5:有哪些解決死鎖問題的策略

    • 1.死鎖語法,不讓死鎖發生

      • 破壞死鎖的四個條件之一;如:哲學家換手、轉賬換序
    • 2.死鎖避免

      • 銀行家算法、系統安全序列
    • 3.死鎖檢查與恢復

      • 適用資源請求分配圖,一段時間內檢查死鎖,有死鎖就恢復策略,採用恢復策略;
      • 恢復方法:進程終止 、資源剝奪
    • 4.鴕鳥策略(忽略死鎖)

      • 先忽略,後期再讓人工恢復

    面試題6:死鎖避免策略和檢測與恢復策略的主要思路是什麼

    • 死鎖語法

      • 破壞死鎖的四大條件之一
    • 死鎖避免

      • 找到安全序列,銀行家算法
    • 死鎖檢測與恢復

      • 資源請求分配圖

    面試題7:講一講經典的哲學家就餐問題,如何解決死鎖

    • 什麼時候死鎖

      • 哲學家各拿起自己左手邊的筷子,又去請求拿右手邊筷子循環請求時而阻塞
    • 如何解決死鎖

      • 1.一次兩隻筷子,形成原子性操作
      • 2.只允許4個人拿有筷子

    面試題8:實際開發中如何避免死鎖

    • 設置超時時間
    • 多使用併發類而不是自己設計鎖
    • 盡量降低鎖的使用粒度:用不同的鎖而不是一個鎖,鎖的範圍越小越好
    • 避免鎖的嵌套:MustDeadLock類
    • 分配資源前先看能不能收回來:銀行家算法
    • 盡量不要幾個功能用同一把鎖:專鎖專用
    • 給你的線程起個有意義的名字:debug和排查時事半功倍,框架和JDK都遵守這個最佳實踐

    面試題9:什麼是活躍性問題?活鎖、飢餓和死鎖有什麼區別

    • 活鎖

      • 雖然線程並沒有阻塞,也始終在運行(所以叫做“活”鎖,線程是“活”的),但是程序卻得不到進展,因為線程始終互相謙讓,重複做同樣的事

      • 工程中的活鎖實例:消息隊列,消息如果處理失敗,就放在隊列開頭重試,沒阻塞程序無法繼續

      • 如何解決活鎖問題

        • 加入隨機因素,以太網的指數退避算法
    • 飢餓

      • 當線程需要某些資源(例如CPU),但是卻始終得不到,可能原因是飢餓線程的優先級過低

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

    【其他文章推薦】

    ※為什麼 USB CONNECTOR 是電子產業重要的元件?

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

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

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

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