java面試——2021校招提前批字節飛書後端面試問題集合

介紹一下微服務秒殺項目

redis成爲熱點怎麼辦?

利用的redis的(主從、哨兵、集羣)做壓力的均分

集羣怎麼解決

 

nginx負載均衡、配置、權重算法實現

 

令牌桶、漏桶區別,使用場景

 

jwt結構、爲什麼用jwt

JWT 的原理是,服務器認證以後,生成一個 JSON 對象,發回給用戶,就像下面這樣。

 {
  "姓名": "張三",
  "角色": "管理員",
  "到期時間": "2018年7月1日0點0分"
}

以後,用戶與服務端通信的時候,都要發回這個 JSON 對象。服務器完全只靠這個對象認定用戶身份。爲了防止用戶篡改數據,服務器在生成這個對象的時候,會加上簽名(詳見後文)。服務器就不保存任何 session 數據了,也就是說,服務器變成無狀態了,從而比較容易實現擴展。

使用JWT的原因

    鑑權邏輯無需訪問數據庫,任何情況下都不會擊穿緩存打到數據庫影響業務;
    與數據庫解耦,橫向擴容性佳,Token發放、驗證都可以脫離數據庫
    同樣是提供Token,但JWT中可附帶允許的權限/操作,業務無需實現複雜的權限控制邏輯,只需要判斷Token中是否有對應權限即可;
    數據平臺主要的功能就是提供數據訪問接口與數據上傳接口,沒有傳統Web應用的那種上下文關係。過重的鑑權邏輯不太符合當前業務特點;
    使用多版本私鑰,通過更改固定版本簽名所用的私鑰可以批量廢除發出的Token;使用Redis等緩存後亦可實現對單一Token的回收
    業務只有上傳/拉取這兩個操作,只需要區分當前用戶是誰即可

oauth2流程、有安全風險嗎、state參數瞭解嗎

新浪微博作爲服務提供商,擁有用戶的頭像、暱稱、郵箱、好友以及所有的微博內容,簡書希望獲取用戶存儲在微博的頭像和暱稱,假設它們是三個人:

  1. 簡書問新浪微博:我想要獲取用戶 A 的頭像和暱稱,請你提供
  2. 微博說:我需要經過用戶A 本人的許可,然後去問用戶 A 是否要授權簡書訪問自己的頭像和暱稱
  3. 用戶 A 對微博說:我給簡書一個臨時的鑰匙,如果他給你出示了這把鑰匙,你就把我的資料給他
  4. 簡書使用戶給它的鑰匙獲取用戶頭像和暱稱信息。

以上是 OAuth 認證的大概流程。在使用微博授權之前,簡書需要先在微博開放平臺上註冊應用,填寫自己的名稱、logo、用途等信息,微博開放平臺頒發給簡書一個應用 ID 和叫 APP Secret 的密鑰,在實際對接中,會使用到這兩個參數。

state 參數是爲了保證申請 code 的設備和使用 code 的設備的一致而存在的。

對於開發者而言,要修復這個漏洞,就是必須加入state參數,這個參數既不可預測,又必須可以充分證明client和當前第三方網站的登錄認證狀態存在關聯(如果存在過期時間更好)。其實,隨機算一個字符串,然後保存在session,回調時檢查state參數和session裏面的值,就滿足要求了。state生成隨機算一個字符串,然後保存在當前用戶的session,回調時檢查state參數和當前用戶session裏面的值是否一致.攻擊者無法猜對方的state值是多少.  就無法拼出用於攻擊的url.。

csrf攻擊是什麼?怎麼防範

一般來說,攻擊者通過僞造用戶的瀏覽器的請求,向訪問一個用戶自己曾經認證訪問過的網站發送出去,使目標網站接收並誤以爲是用戶的真實操作而去執行命令。常用於盜取賬號、轉賬、發送虛假消息等。攻擊者利用網站對請求的驗證漏洞而實現這樣的攻擊行爲,網站能夠確認請求來源於用戶的瀏覽器,卻不能驗證請求是否源於用戶的真實意願下的操作行爲。

防範手段:

1 驗證 HTTP Referer 字段:HTTP頭中的Referer字段記錄了該 HTTP 請求的來源地址。在通常情況下,訪問一個安全受限頁面的請求來自於同一個網站,而如果黑客要對其實施 CSRF攻擊,他一般只能在他自己的網站構造請求。因此,可以通過驗證Referer值來防禦CSRF 攻擊。

2 關鍵操作頁面加上驗證碼,後臺收到請求後通過判斷驗證碼可以防禦CSRF。但這種方法對用戶不太友好。

3 在請求地址中添加token並驗證:CSRF 攻擊之所以能夠成功,是因爲黑客可以完全僞造用戶的請求,該請求中所有的用戶驗證信息都是存在於cookie中,因此黑客可以在不知道這些驗證信息的情況下直接利用用戶自己的cookie 來通過安全驗證。要抵禦 CSRF,關鍵在於在請求中放入黑客所不能僞造的信息,並且該信息不存在於 cookie 之中。可以在 HTTP 請求中以參數的形式加入一個隨機產生的 token,並在服務器端建立一個攔截器來驗證這個 token,如果請求中沒有token或者 token 內容不正確,則認爲可能是 CSRF 攻擊而拒絕該請求。這種方法要比檢查 Referer 要安全一些,token 可以在用戶登陸後產生並放於session之中,然後在每次請求時把token 從 session 中拿出,與請求中的 token 進行比對,但這種方法的難點在於如何把 token 以參數的形式加入請求。對於 GET 請求,token 將附在請求地址之後,這樣 URL 就變成 http://url?csrftoken=tokenvalue。而對於 POST 請求來說,要在 form 的最後加上 <input type="hidden" name="csrftoken" value="tokenvalue"/>,這樣就把token以參數的形式加入請求了。

4 在HTTP 頭中自定義屬性並驗證:這種方法也是使用 token 並進行驗證,和上一種方法不同的是,這裏並不是把 token 以參數的形式置於 HTTP 請求之中,而是把它放到 HTTP 頭中自定義的屬性裏。通過 XMLHttpRequest 這個類,可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性,並把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便,同時,通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄,也不用擔心 token 會透過 Referer 泄露到其他網站中去。

rabbitmq協議、如何保證消息被投遞(看到過但是沒了解)

1.通過AMOP提供的事務機制:

2消息的確認機制 從confirm機制  在發送完消息後可以通過WaitForConfirm等待消息的投遞結果,這裏有個可選參數,就是阻塞等待的時間,如果返回結果爲false則表示消息投遞失敗,則發送端這時候也就可以採取重試之類的策略了。一種同步的,一種異步通知的:異步回調的方式也就是通道訂閱RabbitMQ的發送完畢確認事件,消息投遞成功會回調這個方法給發送方,回調的參數包含當前消息在該通道中發送的編號DeliveryTag(批量提交的時候可以根據這個編號對應提交集合的索引,保證對應集合索引上的消息可靠投遞)

Exchange類型

三種類型:Direct exchange  Topic exchange(可以使用通配符)  Fanout exchange

netty拆包 解決粘包和拆包的四種解決方案

在RPC框架中,粘包和拆包問題是必須解決一個問題,因爲RPC框架中,各個微服務相互之間都是維繫了一個TCP長連接,比如dubbo就是一個全雙工的長連接。由於微服務往對方發送信息的時候,所有的請求都是使用的同一個連接,這樣就會產生粘包和拆包的問題

粘包和拆包

產生粘包和拆包問題的主要原因是,操作系統在發送TCP數據的時候,底層會有一個緩衝區,例如1024個字節大小,如果一次請求發送的數據量比較小,沒達到緩衝區大小,TCP則會將多個請求合併爲同一個請求進行發送,這就形成了粘包問題;如果一次請求發送的數據量比較大,超過了緩衝區大小,TCP就會將其拆分爲多次發送,這就是拆包,也就是將一個大的包拆分爲多個小包進行發送。如下圖展示了粘包和拆包的一個示意圖:

對於粘包和拆包問題,常見的解決方案有四種:

  • 客戶端在發送數據包的時候,每個包都固定長度,比如1024個字節大小,如果客戶端發送的數據長度不足1024個字節,則通過補充空格的方式補全到指定長度;
  • 客戶端在每個包的末尾使用固定的分隔符,例如\r\n,如果一個包被拆分了,則等待下一個包發送過來之後找到其中的\r\n,然後對其拆分後的頭部部分與前一個包的剩餘部分進行合併,這樣就得到了一個完整的包;
  • 將消息分爲頭部和消息體,在頭部中保存有當前整個消息的長度,只有在讀取到足夠長度的消息之後纔算是讀到了一個完整的消息;
  • 通過自定義協議進行粘包和拆包的處理

 Netty提供的粘包拆包解決方案

3.1 FixedLengthFrameDecoder

對於使用固定長度的粘包和拆包場景,可以使用FixedLengthFrameDecoder,該解碼一器會每次讀取固定長度的消息,如果當前讀取到的消息不足指定長度,那麼就會等待下一個消息到達後進行補足。其使用也比較簡單,只需要在構造函數中指定每個消息的長度即可。這裏需要注意的是,FixedLengthFrameDecoder只是一個解碼一器,Netty也只提供了一個解碼一器,這是因爲對於解碼是需要等待下一個包的進行補全的,代碼相對複雜,而對於編碼器,用戶可以自行編寫,因爲編碼時只需要將不足指定長度的部分進行補全即可。

3.2 LineBasedFrameDecoder與DelimiterBasedFrameDecoder

對於通過分隔符進行粘包和拆包問題的處理,Netty提供了兩個編解碼的類,LineBasedFrameDecoder和DelimiterBasedFrameDecoder。這裏LineBasedFrameDecoder的作用主要是通過換行符,即\n或者\r\n對數據進行處理;而DelimiterBasedFrameDecoder的作用則是通過用戶指定的分隔符對數據進行粘包和拆包處理。同樣的,這兩個類都是解碼一器類,而對於數據的編碼,也即在每個數據包最後添加換行符或者指定分割符的部分需要用戶自行進行處理。

3.3 LengthFieldBasedFrameDecoder與LengthFieldPrepender

這裏LengthFieldBasedFrameDecoder與LengthFieldPrepender需要配合起來使用,其實本質上來講,這兩者一個是解碼,一個是編碼的關係。它們處理粘拆包的主要思想是在生成的數據包中添加一個長度字段,用於記錄當前數據包的長度。LengthFieldBasedFrameDecoder會按照參數指定的包長度偏移量數據對接收到的數據進行解碼,從而得到目標消息體數據;而LengthFieldPrepender則會在響應的數據前面添加指定的字節數據,這個字節數據中保存了當前消息體的整體字節數據長度。LengthFieldBasedFrameDecoder的解碼過程如下圖所示:

3.4 自定義粘包與拆包器

對於粘包與拆包問題,其實前面三種基本上已經能夠滿足大多數情形了,但是對於一些更加複雜的協議,可能有一些定製化的需求。對於這些場景,其實本質上,我們也不需要手動從頭開始寫一份粘包與拆包處理器,而是通過繼承LengthFieldBasedFrameDecoder和LengthFieldPrepender來實現粘包和拆包的處理。

如果用戶確實需要不通過繼承的方式實現自己的粘包和拆包處理器,這裏可以通過實現MessageToByteEncoder和ByteToMessageDecoder來實現。這裏MessageToByteEncoder的作用是將響應數據編碼爲一個ByteBuf對象,而ByteToMessageDecoder則是將接收到的ByteBuf數據轉換爲某個對象數據。通過實現這兩個抽象類,用戶就可以達到實現自定義粘包和拆包處理的目的。如下是這兩個類及其抽象方法的聲明:

public abstract class ByteToMessageDecoder extends ChannelInboundHandlerAdapter {
    protected abstract void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) 
        throws Exception;
}

public abstract class MessageToByteEncoder<I> extends ChannelOutboundHandlerAdapter {
    protected abstract void encode(ChannelHandlerContext ctx, I msg, ByteBuf out) 
        throws Exception;
}

128. 最長連續序列

class Solution {
    public int longestConsecutive(int[] nums) {
        Set<Integer> num_set = new HashSet<Integer>();
        for (int num : nums) {
            num_set.add(num);
        }

        int longestStreak = 0;

        for (int num : num_set) {
            if (!num_set.contains(num - 1)) {
                int currentNum = num;
                int currentStreak = 1;

                while (num_set.contains(currentNum + 1)) {
                    currentNum += 1;
                    currentStreak += 1;
                }

                longestStreak = Math.max(longestStreak, currentStreak);
            }
        }

        return longestStreak;
    }
}

Spring爲什麼是final

MVCC

多版本併發控制,他無非就是樂觀鎖的一種實現方式。在Java編程中,如果把樂觀鎖看成一個接口,MVCC便是這個接口的一個實現類而已。

基本原理

MVCC的實現,通過保存數據在某個時間點的快照來實現的。這意味着一個事務無論運行多長時間,在同一個事務裏能夠看到數據一致的視圖。根據事務開始的時間不同,同時也意味着在同一個時刻不同事務看到的相同表裏的數據可能是不同的。

基本特徵

  • 每行數據都存在一個版本,每次數據更新時都更新該版本。
  • 修改時Copy出當前版本隨意修改,各個事務之間無干擾。
  • 保存時比較版本號,如果成功(commit),則覆蓋原記錄;失敗則放棄copy(rollback)

有沒有大表優化經歷(沒有,但是瞭解一些)

數據中的大表的查詢優化操作

1優化shema、sql語句+索引;

2第二加緩存,memcached, redis;

3主從複製,讀寫分離;

4垂直拆分,根據你模塊的耦合度,將一個大的系統分爲多個小的系統,也就是分佈式系統;

5水平切分,針對數據量大的表,這一步最麻煩,最能考驗技術水平,要選擇一個合理的sharding key, 爲了有好的查詢效率,表結構也要改動,做一定的冗餘,應用也要改,sql中儘量帶sharding key,將數據定位到限定的表上去查,而不是掃描全部的表;

輸入url發生的事情:就從計算機網絡幾個層講了一下

1. 瀏覽器首先判斷使用的是什麼協議(ftp/http),然後對URL進行安全檢查。最後瀏覽器查看緩存,如果請求的對象在緩存中並且是比較新的。那麼直接跳到步驟9

2. 瀏覽器請求OS返回服務器的IP地址

3. 操作系統啓動DNS查詢並向瀏覽器返回服務器的IP地址  

4. 瀏覽器使用TCP協議建立與服務器的連接

5. 瀏覽器通過TCP連接發出HTTP請求

6. 瀏覽器收到HTTP響應。這時候瀏覽器可能關閉TCP連接,或者繼續使用它來請求其他數據。

7. 瀏覽器檢查響應報文的狀態碼。並根據不同的狀態碼做不同的處理。

8. 如果響應是可緩存的,那麼就存儲在緩存區。

9. 瀏覽器解碼響應報文(比如文件是壓縮的就需要解壓縮)

10. 瀏覽器渲染響應的數據。

http有哪些header

每個HTTP請求和響應都會帶有相應的頭部信息。默認情況下,在發送XHR請求的同時,還會發送下列頭部信息:

  • Accept:瀏覽器能夠處理的內容類型
  • Accept-Charset:瀏覽器能夠顯示的字符集
  • Accept-Encoding:瀏覽器能夠處理的壓縮編碼
  • Accept-Language:瀏覽器當前設置的語言
  • Connection:瀏覽器與服務器之間連接的類型
  • Cookie:當前頁面設置的任何Cookie
  • Host:發出請求的頁面所在的域
  • Referer:發出請求的頁面的URL
  • User-Agent:瀏覽器的用戶代理字符串

HTTP響應頭部信息:

  • Date:表示消息發送的時間,時間的描述格式由rfc822定義
  • server:服務器名字。
  • Connection:瀏覽器與服務器之間連接的類型
  • content-type:表示後面的文檔屬於什麼MIME類型
  • Cache-Control:控制HTTP緩存

http狀態碼

 TCP三次握手,四次揮手

TCP建立連接時socket相關函數:

socket的基本操作:
(1)socket()函數:
(2)bind()函數:
(3)listen(),connect()函數;
(4)accept()函數;
(5)socket中的發送與接收函數:
(6)close()函數:
(7)服務器上調用socket函數:
(8)客戶端調用socket函數:
(9)IP地址轉換函數:inet_pton, inet_ntop, inet_addr:

TCP擁塞控制,流量控制:慢開始等

 

滑動窗口

 

UDP如何實現可靠連接:我就說在報文數據段自己定義一下相關字段,在應用層實現可靠的操作

 

GET、POST

進程和線程區別

進程是資源分配的最小的單位,線程是執行的最小的單位,。

進程是資源分配的最小單位,線程是程序執行的最小單位進程是系統中正在運行的一個程序,程序一旦運行就是進程。一個進程可以擁有多個線程,每個線程使用其所屬進程的棧空間。線程與進程的一個主要區別是,同一進程內的一個主要區別是,同一進程內的多個線程會共享部分狀態,多個線程可以讀寫同一塊內存(一個進程無法直接訪問另一進程的內存)。同時,每個線程還擁有自己的寄存器和棧,其他線程可以讀寫這些棧內存。

進程控制塊PCB

 

進程間如何通訊方法:

信號量 內存共享 socket 管道通信 消息隊列

線程間如何通訊:

使用volatile關鍵字

使用Object類的wait() 和 notify() 方法、

使用JUC工具類 CountDownLatch、基本LockSupport實現線程間的阻塞和喚醒

進程有哪些狀態,狀態切換

堆、棧:我從JVM角度答的

 

Mysql事務怎麼聲明

 

Mysql索引結構

 

索引類型:這個當時沒反應過來是什麼

 

引擎Mysam和Innodb區別

 

B+樹

 

Mysql幾種隔離級別,讀已提交,可重複讀

 

網站如何防止重複提交

 

redis幾種數據類型

 

redis String類型自增的命令:inc

 

linux父子進程,fork(),如何判斷哪個是父哪個是子進程

 

一個二維數組循環的時候是按行讀還是按列讀快,我從緩存角度答了一下按行讀快。

 

easy算法題:

單例模式

大數相加

redis爲什麼快

redis有沒有併發問題

redis的數據結構

sorted set的使用場景和底層實現,複雜度

mybatis的緩存

spring boot和spring的優劣勢

mysql的索引

給定一個表,獲取所有課程得分均大於80分的學生的平均得分

有一個 1GB 大小的文件,文件裏每一行是一個詞,每個詞的大小不超過 16B,內存大小限制是 1MB,要求返回頻數最高的 100 個詞

二叉樹的對稱性判斷,判斷一顆二叉樹是否對稱

網絡

1.http和https區別

2.說一下加密算法(說的比較詳細,面試官讓簡單點說)

多線程

1.synchronized和lock區別

2.說一下各自原理

3.樂觀鎖悲觀鎖說一下

4.syn和lock是樂觀還是悲觀

5.樂觀鎖有啥?原理和ABA問題

6.重入鎖說一下

OS

1.頁面置換算法

2.LRU緩存,讓我設計LRU思路,這個還得好好看啊,說的稀裏糊塗的,還好沒讓手撕(有點涼)

JVM

1.說一下垃圾回收這塊,知道的都說出來吧

2.新生代和老年代都用什麼算法?

3.雙親委派說一下

4.類加載過程

數據庫

1.索引作用?

2.索引的數據結構

3.聚簇索引是什麼?

4.innodb是什麼索引?

5.查字典是什麼索引?

代碼

1.單例模式(寫的雙重檢驗)

追問syn和volatile作用

2.Z字型遍歷二叉樹

2.編程,leetcode03

網絡

3.http和https的區別

4.https建立連接的過程

5.https抓包工具是如何實現的

語言

6.java的equals()和==的區別

7.java常用的容器有哪些

8.java的多態和繼承是如何實現的

9.java的內存管理機制

10.java多線程中的鎖你用過哪些

操作系統

11.進程間通信哪幾種方式

12.線程間通信有哪幾種方式

13.虛擬內存,共享內存和常駐內存的區別

14.虛擬地址,邏輯地址和物理地址的區別

15.邏輯地址如何轉成物理地址

16.死鎖發生的條件

一面:

1. 從瀏覽器敲入baidu.com到回車的過程中發生了什麼

2. client 如何通過ip地址找到目標機器(路由轉發)

3. 瞭解arp嗎

4. http和https的區別

5. redis有哪些數據結構? 如何用這些數據結構實現一個發佈訂閱的功能?

6. kafka爲什麼快?好處在哪?(主要是實習中用到了kafka)

7. 字符串壓縮算法瞭解過嗎?

8. threadlocal知道嗎,如果讓你實現一個類似的功能你如何實現?(當時不記得threadlocal了,然後面試官給了我個場景,讓我實現以下。。我說用map然後key是thread的地址,value是存儲變量)

9. 100w個數據求出前100大的數據

10. 手撕單例模式,雙重判斷

11. 單例模式爲啥要用volatile,volatile的原理

12. jvm的數據結構?堆的結構?minor gc的算法?年輕代gc後沒死的對象放哪?如何才能進入老年代,沒進入老年代的從from to區間中的存放過程是怎樣的(複製算法)?

13. 12m的對象放入年輕代10m的堆中會發生什麼?(主要看老年代是否夠大)

14. OOM後如何定位問題在哪?

二面:

主要是問項目

1. redis的緩存穿透問題如何解決?

2. 在實習時數據庫性能優化你做了什麼工作?

3. 瞭解grpc嗎?

4. 你是如何測試dubbo dfs thrift三種rpc性能的,簡單說說。(還和我討論了下不同序列化方式對性能影響)

5. 你是如何解決你實習過程中full gc問題的

6. 從瀏覽器敲入baidu.com到回車的過程中發生了什麼

7. left join 和 inner join的區別

算法題:

1. leetcode 二叉樹右視圖(我用bfs寫的,其實也可以用dfs;我說我做過,然後面試官說那就快點寫完進入下一題吧😂)

2. o表示住戶,x表示快遞櫃地點。輸出每個用戶到快遞櫃的最近距離

輸入:

o o o

o x o

o x o

輸出

2 1 2

1 0 1

1 0 1

1、項目

2、進程和線程的區別

3、進程之間的通信

4、線程之間的同步

5、Java裏面的鎖,優先隊列

6、TCP如何做到可靠性、TCP爲什麼四次分手

7、數據庫底層結構、B和B+樹的區別,數據庫如何建索引,最左匹配是什麼

8、hashmap講一下

算法題:

1. 實現一個內存操作安全的memcpy函數,函數原型如下(看我用Java就不做了):void *memcpy(void *dst, void * src, size_t size);

2. 給定一個二叉查找樹和一個數字N,請找出二叉查找樹中大於等於N的最小節點。

3. 求一個數組的大於K且與K差距最小的子集,比如[65,30,52,17,98,20]這樣一個數組,

求它的一個和大於等於100,且與100差值最小的那個子集,這個例子的最終輸出回事[30,52,20].因爲這個子集和爲102,是原數組所有和大於等於100中的子集裏與100差值最小的那個。

4. 兩個線程交替打印,線程1先開始打印數字1,線程2接着打印字母a,接着線程1打印數字2,線程2打印字母b,依次類推,每個線程各打印5次。

算法:鏈表奇數位升序、偶數位降序->得到一個最終升序

基礎:

TCP-三次握手/四次握手的必必要性

go相關go協程爲什麼輕量?

其他的忘了,反正很基礎

算法:鏈表k個一旋轉

項目&實習情況

redis的zset

如果讓你實現kafka(自己說項目中用到過、自己給自己挖坑)如何實現?

如果你實現的kafka按照時間來查找並消費你怎麼做?

分佈式鎖你怎麼實現?

TCP-三次握手/四次握手的必必要性

操作系統的內存管理-->段頁式->邏輯地址到物理地址的映射->TLB

mysql的引擎

mysql的索引

b樹 b+樹區別、各自優缺點

問背景、家庭情況

項目&實習情況

如何建立索引

mysql索引的建立什麼情況下那些列會生效之類的

es的底層原理(???)

算法:一個循環數組(是循環的嗎?我那時候有點眼花記不清了),相鄰的不可同時拿,問怎麼拿值最大時間O(n) 空間O(1)?、LFU 時間O(1)、我特麼看了LRU的O(1)咋就沒看LFU的O(1)

結果式倆算法題一緊張都沒做來  哭

第一個算法:如果不是循環的跳梯子dp,循環的話那我zhen'bu'h

第二個算法:一個map (頻率->頻率下的map(key->節點)) ,節點{key,freq}

說一下TCP和UDP協議的頭部數據

HTTP2.0有哪些改動。

keep-alive是1.0還是1.1加進去的

http默認端口號是什麼

說一下https,爲什麼安全,具體說一下https建立連接的流程

redis用過嗎

說一下redis五種數據類型,置換算法說一下(FIFO,LRU,LFU)

用redis五種數據類型,手撕一個LRU算法(說了思路,不會。當時說的是用hash做儲存,list實現一個雙向鏈表維護)

redis的hashmap和java的hashmap有何異同

數據庫學過嗎?

說一下建索引用索引的條件,索引的弊端

有沒有遇到過建了索引但是沒走索引這種情況

給一個Linux 命令說明這命令幹什麼的   drwxr-xr-x 7 chris staff 224B Mar 4 11:20 go(太菜,不記得了,曾經似乎看到過)

給一個學生表,一個成績表,查詢性別是女的學生的成績和姓名,按降序排列

說一下左連接和內連接的區別

然後一個動態規劃題,給你一個日誌文件,上面有每個用戶登錄登出時刻,求每一時刻同時在線的人數

logs[] = [[1,0,1],[2,2,3],[3,0,5]]

日誌格式 是 uid,login_time,logout_time ,要求算法時間複雜度爲O(n),只寫出O(n^2)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章