php面試問題及回答技巧?一、寫一段代碼判斷單向鍊表中有沒有形成環，如果形成環，請找出環的入口處，即 P 點，我來為大家科普一下關于php面試問題及回答技巧?以下内容希望對你有幫助!

php面試問題及回答技巧

一、寫一段代碼判斷單向鍊表中有沒有形成環，如果形成環，請找出環的入口處，即 P 點

/*

*單鍊表的結點類

*/

class LNode{

//為了簡化訪問單鍊表,結點中的數據項的訪問權限都設為public

public int data;

public LNode next;

}

class LinkListUtli {

//當單鍊表中沒有環時返回null，有環時返回環的入口結點

public static LNode searchEntranceNode(LNode L)

{

LNode slow=L;//p表示從頭結點開始每次往後走一步的指針

LNode fast=L;//q表示從頭結點開始每次往後走兩步的指針

while(fast !=null && fast.next !=null)

{

if(slow==fast) break;//p與q相等，單鍊表有環

slow=slow.next;

fast=fast.next.next;

}

if(fast==null || fast.next==null) return null;

// 重新遍曆，尋找環的入口點

slow=L;

while(slow!=fast)

{

slow=slow.next;

fast=fast.next;

}

return slow;

}

}

二、從撲克牌中随機抽出 5 張牌，判斷是不是一個順子，即這5張牌是連續的

這個問題有個關鍵點，撲克牌，1-13 不能再多了。這就很簡單了。用PHP來做，定義一個數組分别存着1到13, 拿出一個，置空一個，最後看下這五個置空的 是不是連續的。這種情況不考慮抽出的順序。

三、說一下 PHP 的（内存）垃圾回收機制

每一個變量對應一個 zval 數據結構，在該結構内還有一個 val 結構體，該結構體内有一個引用計數（php7 而言，對于 php5，這個引用計數是保存在 zval 結構中的），标識該對象的引用數，當對象的引用計數為 0 時代表這個對象可被回收。

對象的 refcount 減少的時機：修改變量、函數返回（釋放局部變量）、unset 變量

對于數組和對象而言，可能存在變量中的成員引用變量本身的情況，也就是循環引用，這樣會造成這個變量永遠不會被内存回收，而成為垃圾。

PHP 裡對于這種情況給出了垃圾回收機制：如果數組、對象的引用計數減少而且不為零，則認為他們可能是垃圾，把他們放到垃圾收集器裡。等垃圾收集器到了一定的數量之後，進行垃圾處理：對所有可能的垃圾 refcount 減 1，如果為 1，說明是垃圾，則進行内存回收；如果不為 1，說明還有其他變量在使用，refcount 重新加 1；這種對象複用以及垃圾回收機制在其他語言中也有體現：redis 中也使用了引用計數表示每個對象的引用數量。

四、簡述一下PHP短信驗證碼如何防刷？

1、時間限制：60 秒後才能再次發送

從發送驗證碼開始，前端（客戶端）會進行一個 60 秒的倒數，在這一分鐘之内，用戶是無法提交多次發送信息的請求的。這種方法雖然使用得比較普遍，但是卻不是非常有用，技術稍微好點的人完全可以繞過這個限制，直接發送短信驗證碼。

2、手機号限制：同一個手機号，24 小時之内不能夠超過 5 條

對使用同一個手機号碼進行注冊或者其他發送短信驗證碼的操作的時候，系統可以對這個手機号碼進行限制，例如，24 小時隻能發送 5 條短信驗證碼，超出限制則進行報錯（如：系統繁忙，請稍後再試）。然而，這也隻能夠避免人工手動刷短信而已，對于批量使用不同手機号碼來刷短信的機器，這種方法也是無可奈何的。

3、短信驗證碼限制：30 分鐘之内發送同一個驗證碼

網上還有一種方法說：30 分鐘之内，所有的請求，所發送的短信驗證碼都是同一個驗證碼。第一次請求短信接口，然後緩存短信驗證碼結果，30 分鐘之内再次請求，則直接返回緩存的内容。對于這種方式，不是很清楚短信接口商會不會對發送緩存信息收取費用，如果有興趣可以了解了解。

4、前後端校驗：提交 Token 參數校驗

這種方式比較少人說到，個人覺得可以這種方法值得一試。前端（客戶端）在請求發送短信的時候，同時向服務端提交一個 Token 參數，服務端對這個 Token 參數進行校驗，校驗通過之後，再向請求發送短信的接口向用戶手機發送短信。

5、唯一性限制：微信産品，限制同一個微信 ID 用戶的請求數量

如果是微信的産品的話，可以通過微信 ID 來進行識别，然後對同一個微信 ID 的用戶限制，24 小時之内最多隻能夠發送一定量的短信。

6、産品流程限制：分步驟進行

例如注冊的短信驗證碼使用場景，我們将注冊的步驟分成 2 步，用戶在輸入手機号碼并設置了密碼之後，下一步才進入驗證碼的驗證步驟。

7、圖形驗證碼限制：圖形驗證通過後再請求接口

用戶輸入圖形驗證碼并通過之後，再請求短信接口獲取驗證碼。為了有更好的用戶體驗，也可以設計成：一開始不需要輸入圖形驗證碼，在操作達到一定量之後，才需要輸入圖形驗證碼。具體情況請根據具體場景來進行設計。

8、IP 及 Cookie 限制：限制相同的 IP/Cookie 信息最大數量

使用 Cookie 或者 IP，能夠簡單識别同一個用戶，然後對相同的用戶進行限制（如：24 小時内最多隻能夠發送 20 條短信）。然而，Cookie 能夠清理、IP 能夠模拟，而且 IP 還會出現局域網相同 IP 的情況，因此，在使用此方法的時候，應該根據具體情況來思考。

9、短信預警機制，做好出問題之後的防護

以上的方法并不一定能夠完全杜絕短信被刷，因此，我們也應該做好短信的預警機制，即當短信的使用量達到一定量之後，向管理員發送預警信息，管理員可以立刻對短信的接口情況進行監控和防護。

五、mySQL 裡有 2000w 數據，redis 中隻存 20w 的數據，如何保證 redis 中的數據都是熱點數據

相關知識：redis 内存數據集大小上升到一定大小的時候，就會施行數據淘汰策略（回收策略）。redis 提供 6 種數據淘汰策略：

volatile-lru：從已設置過期時間的數據集（server.db [i].expires）中挑選最近最少使用的數據淘汰

volatile-ttl：從已設置過期時間的數據集（server.db [i].expires）中挑選将要過期的數據淘汰

volatile-random：從已設置過期時間的數據集（server.db [i].expires）中任意選擇數據淘汰

allkeys-lru：從數據集（server.db [i].dict）中挑選最近最少使用的數據淘汰

allkeys-random：從數據集（server.db [i].dict）中任意選擇數據淘汰

no-enviction（驅逐）：禁止驅逐數據

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!