91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲 日韩 欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

b站面試之旅:了解哪些I/O模型?select是阻塞IO嗎?

算法與數(shù)據(jù)結(jié)構(gòu) ? 來源:算法與數(shù)據(jù)結(jié)構(gòu) ? 作者:算法與數(shù)據(jù)結(jié)構(gòu) ? 2020-10-30 09:23 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

此次B站服務(wù)端開發(fā)面試之旅可謂驚險,不過通過對大部分面試題套路的掌握,不出意外還是拿下了,下面我們來看看這些騷題是不是常見的不能再常見的了。這些面試題看了就能面上?當(dāng)然不是,只是通過這些題讓自己知道所欠缺的是什么,以及可以去看看哪些資料。

1 操作系統(tǒng)相關(guān)

自旋鎖和一般鎖的區(qū)別是什么?為什么要使用自旋鎖?

當(dāng)一個線程在獲取鎖的時候,如果這個鎖已經(jīng)被其他線程獲取,那么這個線程不會破門而入,而是循環(huán)等待,但是嗷嗷待哺,需要不斷地嗷嗷叫判斷鎖是否被成功獲取,直到獲取到鎖才會退出循環(huán)。

自旋鎖通常會出現(xiàn)哪些問題?

如果某個線程拿著鎖死不放手,其他線程沒法拿到這把鎖,只好等待獲取鎖的線程進(jìn)入循環(huán)等待的狀態(tài),等待不是睡覺,還是會消耗CPU,等待久了就會導(dǎo)致CPU的使用率太高。

那么自旋鎖和其他鎖到底有啥不同?

從線程狀態(tài)來看,自旋鎖的狀態(tài)是運(yùn)行-運(yùn)行-運(yùn)行。而非自旋鎖的狀態(tài)是運(yùn)行---阻塞---運(yùn)行,所以自旋鎖會更高效。

不管是什么鎖,都是為了實現(xiàn)保護(hù)共享資源而提出的一種鎖機(jī)制,都是為了對某項資源的互斥使用。對于互斥鎖而言,如果資源已經(jīng)被占用,那么資源的申請者只會進(jìn)入睡眠的狀態(tài)。而自旋鎖不會引起調(diào)用者睡眠,而是一直循環(huán)在那里查看該自旋鎖的保持著是否已經(jīng)釋放了鎖。

那么在Java中如何去實現(xiàn)一個自旋鎖

publicclassSpinLock{ privateAtomicReferencecas=newAtomicReference(); publicvoidlock(){ Threadcurrent=Thread.currentThread(); //利用CAS while(!cas.compareAndSet(null,current)){ //DO } } publicvoidunlock(){ Threadcurrent=Thread.currentThread(); cas.compareAndSet(current,null); } }

上段代碼中,方法lock利用的CAS,當(dāng)線程A獲取鎖的時候,成功獲取不會進(jìn)入while循環(huán)。如果此時線程A沒有釋放鎖,當(dāng)線程B來獲取鎖的時候,由于不滿足CAS,就會進(jìn)入whilei循環(huán),不斷判斷是否滿足CAS,直到線程A調(diào)用unlock釋放。

自旋鎖有哪些優(yōu)點(diǎn)?

因為運(yùn)行在用戶態(tài),沒有上下文的線程狀態(tài)切換,線程一直處于active,減少了不必要的上下文切換,從而執(zhí)行速度較快

因為非自旋鎖在沒有獲取鎖的情況下會進(jìn)入阻塞狀態(tài),從而進(jìn)入內(nèi)核態(tài),此時就需要線程的上下文切換,因為阻塞后進(jìn)入內(nèi)核調(diào)度狀態(tài),會導(dǎo)致用戶態(tài)和內(nèi)核態(tài)之間的切換,影響鎖的性能。

了解哪些I/O模型?select是阻塞IO嗎?

首先將IO模型給安排一遍,然后把自己很熟悉的IO模型詳細(xì)說一波并介紹出應(yīng)用場景,這個裝的X就算比較完美,具體的非常詳細(xì)的在下一篇文章,這里簡要說一波。這一部分在上一篇詳細(xì)闡述過

阻塞IO

我們知道在調(diào)用某個函數(shù)的時候無非就是兩種情況,要么馬上返回,然后根據(jù)返回值進(jìn)行接下來的業(yè)務(wù)處理。當(dāng)在使用阻塞IO的時候,應(yīng)用程序會被無情的掛起,等待內(nèi)核完成操作,因為此時的內(nèi)核可能將CPU時間切換到了其他需要的進(jìn)程中,在我們的應(yīng)用程序看來感覺被卡主(阻塞)了。

阻塞IO

非阻塞IO

當(dāng)使用非阻塞函數(shù)的時候,和阻塞IO類比,內(nèi)核會立即返回,返回后獲得足夠的CPU時間繼續(xù)做其他的事情。

非阻塞

IO復(fù)用模型

當(dāng)使用fgets等待標(biāo)準(zhǔn)輸入的時候,如果此時套接字有數(shù)據(jù)但不能讀出。IO多路復(fù)用意味著可以將標(biāo)準(zhǔn)輸入、套接字等都當(dāng)做IO的一路,任何一路IO有事件發(fā)生,都將通知相應(yīng)的應(yīng)用程序去處理相應(yīng)的IO事件,在我們看來就反復(fù)同時可以處理多個事情。這就是IO復(fù)用。

IO復(fù)用

信號驅(qū)動IO

在信號驅(qū)動式 I/O 模型中,應(yīng)用程序使用套接口進(jìn)行信號驅(qū)動 I/O,并安裝一個信號處理函數(shù),進(jìn)程繼續(xù)運(yùn)行并不阻塞。當(dāng)數(shù)據(jù)準(zhǔn)備好時,進(jìn)程會收到一個 SIGIO 信號,可以在信號處理函數(shù)中調(diào)用 I/O 操作函數(shù)處理數(shù)據(jù)。

信號驅(qū)動

異步IO

用程序告知內(nèi)核啟動某個操作,并讓內(nèi)核在整個操作(包括將數(shù)據(jù)從內(nèi)核拷貝到應(yīng)用程序的緩沖區(qū))完成后通知應(yīng)用程序。那么和信號驅(qū)動有啥不一樣?

異步IO

講講select和epoll的區(qū)別?

這里一樣的套路,先說出兩者的用途,然后兩者的優(yōu)缺點(diǎn)。

select的缺點(diǎn)

select返回的是含有整個句柄的數(shù)組,應(yīng)用程序需要遍歷整個數(shù)組才能發(fā)現(xiàn)哪些句柄發(fā)生了事件

select的觸發(fā)方式是水平觸發(fā),應(yīng)用程序如果沒有完成對一個已經(jīng)就緒的文件描述符進(jìn)行IO操作,那么之后每次select調(diào)用還是會將這些文件描述符通知進(jìn)程

內(nèi)核 / 用戶空間內(nèi)存拷貝問題,select每次都會改變內(nèi)核中的句柄數(shù)據(jù)結(jié)構(gòu)集,因而每次select調(diào)用時都需要從用戶空間向內(nèi)核空間復(fù)制所有的句柄數(shù)據(jù)結(jié)構(gòu),產(chǎn)生巨大的開銷

單個進(jìn)程能夠監(jiān)視的文件描述符的數(shù)量存在最大限制,通常是1024,當(dāng)然可以更改數(shù)量

epoll實現(xiàn)

epoll在內(nèi)核中會維護(hù)一個紅黑樹和一個雙向鏈表,紅黑樹存放通過epoll_ctl方法向epoll對象中添加進(jìn)來的事件,所以不需要每次調(diào)用epoll_wait都全量復(fù)制所有的事件結(jié)構(gòu)。雙向鏈表存放就緒的事件,所有添加到epoll中的事件都會與設(shè)備(網(wǎng)卡)驅(qū)動程序建立回調(diào)關(guān)系,也就是說,當(dāng)相應(yīng)的事件發(fā)生時會調(diào)用這個回調(diào)方法,這個回調(diào)方法在內(nèi)核中叫ep_poll_callback,它會將發(fā)生的事件添加到rdlist雙鏈表中。調(diào)用epoll_wait就會直接返回鏈表中的就緒事件,效率高。

select適合少量活躍連接,一般幾千。

epoll適合大量不太活躍的連接。

樂觀鎖和悲觀鎖了解嗎?

這個問題延伸的問題會很多,比如線程安全,CAS原理,優(yōu)缺點(diǎn)等。

啥是悲觀和樂觀,咋們面試的時候不得樂觀一些。想給面試來一波官方解釋,然后大白話解釋一波就差不多了。

官方:悲觀鎖是總是假設(shè)最壞的情況,每次那數(shù)據(jù)都認(rèn)為別人會修改它,所以每次去那數(shù)據(jù)都要上鎖,這樣別人去拿這個數(shù)據(jù)就會阻塞。樂觀鎖就不一樣了,總是覺得一切都是最好的安排,每次拿數(shù)據(jù)都認(rèn)為別人不會修改,所以也就不上鎖,但是在更新的時候會判斷這個期間別人有沒有更新這個數(shù)據(jù)。

什么是緩存穿透?如何避免?什么是緩存雪崩?何如避免?

緩存穿透

一般來說,緩存系統(tǒng)會通過key去緩存查詢,如果不存在對應(yīng)的value,就應(yīng)該去后端系統(tǒng)查找(比如DB)。這個時候如果一些惡意的請求到來,就會故意查詢不存在的key,當(dāng)某一時刻的請求量很大,就會對后端系統(tǒng)造成很大的壓力。這就叫做緩存穿透。

如何避免?

對查詢結(jié)果為空的情況也進(jìn)行緩存,緩存時間設(shè)置短一點(diǎn),或者該key對應(yīng)的數(shù)據(jù)insert了之后清理緩存。對一定不存在的key進(jìn)行過濾??梢园阉械目赡艽嬖诘膋ey放到一個大的Bitmap中,查詢時通過該bitmap過濾。

緩存雪崩

當(dāng)緩存服務(wù)器重啟或者大量緩存集中在某一個時間段失效,這樣在失效的時候,會給后端系統(tǒng)帶來很大壓力。導(dǎo)致系統(tǒng)崩潰。

如何避免?

在緩存失效后,通過加鎖或者隊列來控制讀數(shù)據(jù)庫寫緩存的線程數(shù)量。比如對某個key只允許一個線程查詢數(shù)據(jù)和寫緩存,其他線程等待。

做二級緩存,A1為原始緩存,A2為拷貝緩存,A1失效時,可以訪問A2,A1緩存失效時間設(shè)置為短期,A2設(shè)置為長期。

不同的key,設(shè)置不同的過期時間,讓緩存失效的時間點(diǎn)盡量均勻。

2 redis相關(guān)

如果是后端/服務(wù)端面試的同學(xué),怎么說都的去找一本redis書來看看,其出現(xiàn)的概率只有那么大了,切記切記??纯碆站問了哪幾個問題。

redis的淘汰刪除策略了解嗎?

能說不了解嗎,就算是沒有聽說過,咋們也可以來一句:“不好意思面試官,這一塊還不怎么深入,但是從字面意思來理解巴拉巴拉”,不至于一臉懵逼。下面我們看看redis的緩存策略

Redis中通過maxmemory參數(shù)來設(shè)定內(nèi)存的使用上限,如果Redis所使用內(nèi)存超過設(shè)定的最大值,那么會根據(jù)配置文件中的策略選取要刪除的key來刪除,從而留出新的鍵值空間。主要的六種淘汰key策略

volatile-lru

在鍵空間中設(shè)置過期時間,移除哪些最近最少使用的key,占著茅坑不拉屎的key

allkeys-lru

移除最近最少使用的key

volatile-random

在鍵空間中設(shè)置過期時間,隨機(jī)移除一個key

allkeys-random

隨機(jī)移除一個key

noeviction

當(dāng)內(nèi)存使用達(dá)到閥值的時候,所有引起申請內(nèi)存的命令會報錯;

ok,現(xiàn)在知道了需要淘汰哪些key,那我們?nèi)绾稳ヌ蕴@些key

定時刪除

很簡單,設(shè)置一個鬧鐘,鬧鐘響了就刪除即可。這種方式對于內(nèi)存來說還是比較友好,內(nèi)存不需要啥額外的操作,直接通過定時器就可保證盡快的刪除。對于CPU來說就有點(diǎn)麻煩了,如果過期鍵比較多,那么定時器也就多,這刪除操作就會占用太多的CPU資源

惰性刪除

每次從鍵空間獲取鍵的時候檢查鍵的過期時間,如果過期了,刪除完事。

定期刪除

每隔一段時間就去數(shù)據(jù)庫檢查,刪除過期的鍵

這種方案是定時刪除和惰性刪除的中和方法,既通過限制刪除操作執(zhí)行的時長來減少對CPU時間的影響,也能減少內(nèi)存的浪費(fèi)。但是難點(diǎn)在于間隔時長需要根據(jù)業(yè)務(wù)情況而定。

3 mysql

mysql中使用的鎖有哪些?什么時候使用行鎖,什么時候會使用表鎖?

InnoDB中的行鎖是通過索引上的索引項實現(xiàn),主要特點(diǎn)是,只有通過索引條件檢索數(shù)據(jù),InnoDB才會使用行級鎖,否則InnoDB將使用表鎖。

這里注意,在Mysql中,行級鎖不是鎖記錄而是鎖索引。索引又分為主鍵索引和非主鍵索引兩種。如果在一條語句中操作了非主鍵索引,Mysql會鎖定該非主鍵索引,再鎖定相關(guān)的主鍵索引。

了解過間隙鎖嗎?間隙鎖的加鎖范圍是怎么確定的?

了解B+樹嗎?B+樹什么時候會出現(xiàn)結(jié)點(diǎn)分裂?

這個回答在上一篇的B+樹已經(jīng)詳細(xì)說了。這里簡述一下

將已滿結(jié)點(diǎn)進(jìn)行分裂,將已滿節(jié)點(diǎn)后M/2節(jié)點(diǎn)生成一個新節(jié)點(diǎn),將新節(jié)點(diǎn)的第一個元素指向父節(jié)點(diǎn)。

父節(jié)點(diǎn)出現(xiàn)已滿,將父節(jié)點(diǎn)繼續(xù)分裂。

一直分裂,如果根節(jié)點(diǎn)已滿,則需要分類根節(jié)點(diǎn),此時樹的高度增加。

事務(wù)還沒執(zhí)行完數(shù)據(jù)庫掛了,重啟的時候會發(fā)生什么?

undo日志和redo日志分別是干嘛的?

redo log重做日志是InnDB存儲引擎層的,用來保證事務(wù)安全。在事務(wù)提交之前,每個修改操作都會記錄變更后的數(shù)據(jù),保存的是物理日志-數(shù)據(jù),防止發(fā)生故障的時間點(diǎn),有臟頁未寫入磁盤,在重啟mysql的時候,根據(jù)redo log進(jìn)行重做從而達(dá)到事務(wù)的持久性

undo log回滾日志保存了事務(wù)發(fā)生之前的數(shù)據(jù)的一個版本,可以用于回滾,同時也提供多版本并發(fā)控制下的讀。

簡單講講數(shù)據(jù)庫的MVCC的實現(xiàn)原理?

細(xì)說太多了,幾個大寫字母代表啥,這幾個大寫字母又是如何關(guān)聯(lián)起來完事。細(xì)問再深究

mysql的binlog日志什么時候會使用?

首先應(yīng)該知道binlog是一個二進(jìn)制文件,記錄所有增刪改操作,節(jié)點(diǎn)之間的復(fù)制都會依靠binlog來完成。從底層原理來說,binlog有三個模式

模式1--row模式

每一行的數(shù)據(jù)被修改就會記錄在日志中,然后在slave段對相同的數(shù)據(jù)進(jìn)行修改。比如說"update xx where id in(1,2,3,4,5)",使用此模式就會記錄5條記錄

模式2--statement模式

修改數(shù)據(jù)的sql會記錄到master的binlog中。slave在復(fù)制的時候sql thread會解析成和原來maseter端執(zhí)行過的相同的sql在此執(zhí)行

模式3--mixed模式

mixed模式即混合模式,Mysql會根據(jù)執(zhí)行的每一條具體sql區(qū)分對待記錄的日志形式。那么binlog的主從同步流程到底是咋樣的

binlog同步

流程簡述:

Master執(zhí)行完增刪改操作后都會記錄binlog日志,當(dāng)需要同步的時候會主動通知slave節(jié)點(diǎn),slave收到通知后使用IO THREAD主動去master讀取binlog寫入relay日志(中轉(zhuǎn)日志),然后使 SQL THREAD完成對relay日志的解析然后入庫操作,完成同步。

4 基本數(shù)據(jù)結(jié)構(gòu)

使用LRU時,如果短時間內(nèi)會出現(xiàn)大量只會使用一次的數(shù)據(jù),可能導(dǎo)致之前大量高頻使用的緩存被刪除,請問有什么解決辦法?

了解過循環(huán)鏈表嗎?他的長度怎么計算?

他的主要特點(diǎn)是鏈表中的最后一個節(jié)點(diǎn)的指針域指向頭結(jié)點(diǎn),整個鏈表形成一個環(huán)。*這里*循環(huán)鏈表判斷鏈表結(jié)束的標(biāo)志是,判斷尾節(jié)點(diǎn)是不是指向頭結(jié)點(diǎn)

哪種數(shù)據(jù)結(jié)構(gòu)可以支持快速插入,刪除,查找等操作?

思考這個問題的時候,我們不凡復(fù)習(xí)下不錯的二分查找,它依賴數(shù)組隨機(jī)訪問的特性,其查找時間復(fù)雜度為O(log n)。如果我們將元素放入鏈表中,二分查找還好使嗎?這就是今天和大家分享的跳表

理解跳表

假設(shè)使用單鏈表存儲n個元素,其中元素有序如下圖所示

一級索引

從鏈表中查找一個元素,自然從頭開始遍歷找到需要查找的元素,此時的時間復(fù)雜度為O(n)。那采用什么方法可以提高查詢的效率呢?問就是加索引,如何加,我們從這部分?jǐn)?shù)據(jù)中抽取幾個元素出來作為單獨(dú)的一個鏈表,如下圖所示]

假設(shè)此時咋們查找元素16,首先一級索引處尋找,當(dāng)找到元素14的時候,下一個節(jié)點(diǎn)的值為18,意味著我們尋找的數(shù)在這兩個數(shù)的中間。此時直接從14節(jié)點(diǎn)指針下移到下面的原始鏈表中,繼續(xù)遍歷,正好下一個元素就是我們尋找的16。好了,我們小結(jié)一下,如果從原始鏈表中尋找元素16,需要遍歷比較8次,如果通過索引鏈表尋找我們只需要5次即可。

在這里插入圖片描述

我們繼續(xù)查找元素16,此時比較次數(shù)變?yōu)?次。這樣看來,加一層索引查找的次數(shù)就變少,如果有n個元素到底有多少索引?

假設(shè)我們按照每兩個結(jié)點(diǎn)就抽出一個結(jié)點(diǎn)作為上一層的索引節(jié)點(diǎn),第一層所以節(jié)點(diǎn)個數(shù)n/2,第二層為n/4,第x級索引的結(jié)點(diǎn)個數(shù)是第x-1級索引的結(jié)點(diǎn)個數(shù)的1/2,那第x級索引結(jié)點(diǎn)的個數(shù)就是n/(2^x)。假設(shè)索引有y級,我們可以得到n/(2^y)=2,從而求得y=log2n-1。

這么多索引是不是就很浪費(fèi)內(nèi)存嘞?

假設(shè)原始鏈表大小為n,那第一級索引大約有 n/2 個結(jié)點(diǎn),第二級索引大約有 n/4 個結(jié)點(diǎn),以此類推,每上升一級就減少一半,直到剩下 2 個結(jié)點(diǎn)。如果我們把每層索引的結(jié)點(diǎn)數(shù)寫出來,就是一個等比數(shù)列。這幾級索引的結(jié)點(diǎn)總和就是 n/2+n/4+n/8…+8+4+2=n-2 。所以,跳表的空間復(fù)雜度是 O(n) 。那還能不能降低一些呢。機(jī)智的你應(yīng)該就考慮到假設(shè)每三個結(jié)點(diǎn)抽取一個節(jié)點(diǎn)作為索引鏈表的節(jié)點(diǎn)。

跳表與二叉查找樹

兩者其查找的時間復(fù)雜度均為O(logn) ,那跳表還有哪些優(yōu)勢?

先看二叉查找樹,

特殊二叉查找樹

這種結(jié)構(gòu)會導(dǎo)致二叉查找樹的查找效率變?yōu)?O(n),。

跳表與紅黑樹

說實話,紅黑樹確實比較復(fù)雜,面試的時候讓你寫紅黑樹,你就給他大嘴巴子?

紅黑樹需要通過左右旋的方式去維持樹大小平衡。而跳表是通過隨機(jī)函數(shù)來維護(hù)前面提到的 “ 平衡性 ” 。當(dāng)我們往跳表中插入數(shù)據(jù)的時候,我們可以選擇同時將這個數(shù)據(jù)插入到部分索引層中。如何選擇加入哪些索引層呢?
我們通過一個隨機(jī)函數(shù),來決定將這個結(jié)點(diǎn)插入到哪幾級索引中,比如隨機(jī)函數(shù)生成了值 K ,那我們就將這個結(jié)點(diǎn)添加到第一級到第 K 級這 K 級索引中。當(dāng)我們往跳表中插入數(shù)據(jù)的時候,我們可以選擇同時將這個數(shù)據(jù)插入到部分索引層中。

小結(jié)

Redis中的有序集合采用了跳表的方式來實現(xiàn),其實還采用了散列表等數(shù)據(jù)結(jié)構(gòu)進(jìn)行融合。它在插入,刪除等都有比較快的速度,雖然紅黑樹也可以做到,但是紅黑樹對于按照區(qū)間查找數(shù)據(jù)這個操作,跳表可以做到 O(logn) 的時間復(fù)雜度定位區(qū)間的起點(diǎn),然后在原始鏈表中順序往后遍歷就可以了

平時愛看技術(shù)博客嗎?分享一篇最近的技術(shù)博客?平時上B站嗎?

看的技術(shù)博客多了,這就是嘮嗑。比如說,看看小賤一天天BB的文章,哈哈哈哈哈

面試官:我擦,尼瑪說的這個我都關(guān)注了,難怪我問啥你都能說個一二三。

5 總結(jié)

請記下以下幾點(diǎn):

公司招你去是干活了,不會因為你怎么怎么的而降低對你的要求標(biāo)準(zhǔn)。

工具上面寫代碼和手撕代碼完全不一樣。

珍惜每一次面試機(jī)會并學(xué)會復(fù)盤。

對于應(yīng)屆生主要考察的還是計算機(jī)基礎(chǔ)知識的掌握,項目要求沒有那么高,是自己做的就使勁摳細(xì)節(jié),做測試,只有這樣,才知道會遇到什么問題,遇到什么難點(diǎn),如何解決的。從而可以侃侃而談了。

非科班也不要怕,怕了你就輸了!一定要多嘗試。


責(zé)任編輯:lq


聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • cpu
    cpu
    +關(guān)注

    關(guān)注

    68

    文章

    11281

    瀏覽量

    225100
  • 應(yīng)用程序
    +關(guān)注

    關(guān)注

    38

    文章

    3344

    瀏覽量

    60276
  • select
    +關(guān)注

    關(guān)注

    0

    文章

    28

    瀏覽量

    4262

原文標(biāo)題:B 站面試之旅,一起來看看都問了什么?

文章出處:【微信號:TheAlgorithm,微信公眾號:算法與數(shù)據(jù)結(jié)構(gòu)】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點(diǎn)推薦

    PCA9554:8位I2C和SMBus I/O擴(kuò)展器的深度解析

    遠(yuǎn)程8位I2C和SMBus I/O擴(kuò)展器,具有諸多優(yōu)秀特性,下面我們就來深入了解一下。 文件下載: pca9554.pdf 1. 產(chǎn)品特性 PCA9554的特性豐富,使其在眾多應(yīng)用場景
    的頭像 發(fā)表于 12-27 13:45 ?784次閱讀

    TCA9555:低電壓16位I2C和SMBus I/O擴(kuò)展器的全面解析

    作為一款低電壓16位I2C和SMBus I/O擴(kuò)展器,具有諸多優(yōu)秀特性,下面我們就來詳細(xì)了解一下。 文件下載: tca9555.pdf 一、產(chǎn)品概述 TCA9555專為1.65 - 5
    的頭像 發(fā)表于 12-25 10:05 ?544次閱讀

    深入解析TCA9554:8位I2C和SMBus低功耗I/O擴(kuò)展器

    深入解析TCA9554:8位I2C和SMBus低功耗I/O擴(kuò)展器 在電子設(shè)計領(lǐng)域,I/O擴(kuò)展器是解決微控制器
    的頭像 發(fā)表于 12-23 17:35 ?745次閱讀

    具有阻塞總線恢復(fù)功能的 TCA4307 熱插拔 I2C 總線和 SMBus 緩沖器介紹

    具有阻塞總線恢復(fù)功能的 TCA4307 熱插拔 I2C 總線和 SMBus 緩沖器介紹 在電子設(shè)計領(lǐng)域,熱插拔 I2C 總線緩沖器是實現(xiàn)系統(tǒng)靈活擴(kuò)展和維護(hù)的重要組件。今天,我們就來深入了解
    的頭像 發(fā)表于 12-17 15:40 ?368次閱讀

    飛凌嵌入式ElfBoard-文件I/O的深入學(xué)習(xí)之異步I/O

    I/O多路復(fù)用中,進(jìn)程通過系統(tǒng)調(diào)用select或poll來主動查詢文件描述符上是否可以執(zhí)行I/O操作。而在異步
    發(fā)表于 12-05 11:23

    飛凌嵌入式ElfBoard-文件I/O的深入學(xué)習(xí)之I/O多路復(fù)用

    是為了解決:在并發(fā)式I/O場景中進(jìn)程或線程阻塞到某個I/O系統(tǒng)調(diào)用而出現(xiàn)的技術(shù),使進(jìn)程不
    發(fā)表于 12-05 11:18

    飛凌嵌入式ElfBoard-文件I/O的深入學(xué)習(xí)之阻塞I/O與非阻塞I/O

    1.4.1.1 概念 阻塞I/O顧名思義就是對文件的I/O操作是阻塞式的,即假如對某些類型文件(
    發(fā)表于 12-01 13:07

    飛凌嵌入式ElfBoard-文件I/O了解探究之fcntl和ioctl

    記錄鎖(阻塞版本)const struct flock *0:成功;-1:失敗F_GETOWN獲取異步I/O所有權(quán)無所有權(quán)的進(jìn)程ID(整數(shù))F_SETOWN設(shè)置異步I/
    發(fā)表于 11-28 09:17

    飛凌嵌入式ElfBoard-文件I/O了解探究之I/O緩沖

    前面有提到系統(tǒng)IO和標(biāo)準(zhǔn)IO在緩沖方面的區(qū)別,針對緩沖部分,有一些概念和操作函數(shù)需要了解。1.3.2.1 內(nèi)核緩沖 實際上系統(tǒng)IO在進(jìn)行文件讀寫時并不會直接訪問磁盤設(shè)備,而是僅僅在用戶
    發(fā)表于 11-19 16:24

    淺談光學(xué)I/O模塊的熱挑戰(zhàn)

    服務(wù)器和機(jī)架式網(wǎng)絡(luò)基礎(chǔ)設(shè)施系統(tǒng)內(nèi)的光學(xué) I/O 模塊通常接受主動冷卻系統(tǒng)的直接冷卻,特別是來自機(jī)架式設(shè)備前面板的強(qiáng)制風(fēng)冷。機(jī)架式設(shè)備的散熱設(shè)計需要平衡 I/O 模塊的熱管理與處理器或
    的頭像 發(fā)表于 11-03 09:32 ?779次閱讀
    淺談光學(xué)<b class='flag-5'>I</b>/<b class='flag-5'>O</b>模塊的熱挑戰(zhàn)

    NVMe高速傳輸之?dāng)[脫XDMA設(shè)計30: NVMe 設(shè)備模型設(shè)計

    /O 提交隊列進(jìn)程。 為與待測設(shè)計匹配, NVMe 設(shè)備模型支持最大 16 個 I/O 提交隊列. B
    發(fā)表于 09-29 09:31

    【HZ-RK3568開發(fā)板免費(fèi)體驗】基于 Select Poll的TCP發(fā)服務(wù)器

    并沒有什么優(yōu)越性;關(guān)鍵是能實現(xiàn)同時對多個IO端口進(jìn)行監(jiān)聽,可以等待多個描述符就緒。 I/O復(fù)用模型會用到select、poll,這幾個函數(shù)也
    發(fā)表于 08-19 22:01

    I/O密集型任務(wù)開發(fā)指導(dǎo)

    使用異步并發(fā)可以解決單次I/O任務(wù)阻塞的問題,但是如果遇到I/O密集型任務(wù),同樣會阻塞線程中其它
    發(fā)表于 06-19 07:19

    新升級!功能更強(qiáng)大的串口I/O聯(lián)網(wǎng)模塊,ASK/OOK超外差無線射頻模塊

    本周新品上市串口I/O聯(lián)網(wǎng)模塊超外差無線射頻模塊部分型號參與送樣文末了解詳情↓↓↓MA01-AXCX系列串口I/O聯(lián)網(wǎng)模塊MA01-AXCX
    的頭像 發(fā)表于 06-05 19:32 ?1203次閱讀
    新升級!功能更強(qiáng)大的串口<b class='flag-5'>I</b>/<b class='flag-5'>O</b>聯(lián)網(wǎng)模塊,ASK/OOK超外差無線射頻模塊

    Google I/O 2025大會回顧

    通常,在 I/O 大會的前幾周,我們不會透露太多信息,因為我們會把最重磅的模型留到大會上發(fā)布。但在 Gemini 時代,我們很可能在三月某個周二已經(jīng)推出最智能的模型,或者提前一周公布像
    的頭像 發(fā)表于 05-23 14:54 ?1121次閱讀