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

一、寫一段代碼判斷單向鏈表中有沒有形成環，如果形成環，請找出環的入口處，即 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（驅逐）：禁止驅逐數據