1、通過(guò)哪一個(gè)函數(shù)，可以把錯(cuò)誤轉(zhuǎn)換為異常處理？

A：set_error_handler
B：error_reporting
C：error2exception
D：catch

正確答案：A?

答案分析：set_error_handler() 可指定一個(gè)回調(diào)函數(shù)，錯(cuò)誤發(fā)生時(shí)，會(huì)自動(dòng)通過(guò)指定的回調(diào)函數(shù)處理。在回調(diào)函數(shù)中拋出新的異常即可。

2、下列哪個(gè)shell函數(shù)的描述是正確的?

A：shell函數(shù)可以先調(diào)用后定義
B：shell函數(shù)需使用關(guān)鍵字function定義
C：shell函數(shù)內(nèi)的變量可以聲明為局部變量
D：shell函數(shù)只能通過(guò)return返回值，1是成功，0是失敗

正確答案：C

答案分析：shell函數(shù)必須先定義在調(diào)用；聲明時(shí)，無(wú)需使用關(guān)鍵字；通過(guò)local可以定義函數(shù)內(nèi)的局部變量；shell函數(shù)返回值，0是成功，非0是錯(cuò)誤，其他選項(xiàng)正確

3、下列關(guān)于全文檢索技術(shù)的說(shuō)法，不對(duì)的是：

A: Solr是新一代的全文檢索組件，它比Lucene的搜索效率高很多，還能支持HTTP的訪問(wèn)方式，PHP調(diào)用Solr也很方便。
B: MySQL中把一個(gè)字段建立FULLTEXT索引，就可以實(shí)現(xiàn)全文檢索，目前MyISAM和InnoDB的table都支持FULLTEXT索引。
C: Sphinx是一個(gè)基于SQL的全文檢索引擎，可以結(jié)合MySQL做全文搜索，它可以提供比數(shù)據(jù)庫(kù)本身更專業(yè)的搜索功能。
D: Lucene附帶的二元分詞分析器CJKAnalyzer切詞速度很快，能滿足一般的全文檢索需要。

正確答案：A?

答案分析：?Solr是新一代的全文檢索組件，它基于Lucene，所以說(shuō)它比Lucene快就是胡扯 ：）

4、關(guān)于單例模式的說(shuō)法，錯(cuò)誤的是？

A：?jiǎn)卫Ｊ降哪康氖谴_保在全局環(huán)境中，一個(gè)類只能有一個(gè)實(shí)例存在
B：?jiǎn)卫Ｊ揭话阋v構(gòu)造函數(shù)設(shè)置為 private
C：只需要將構(gòu)造函數(shù)設(shè)置為private 即可確保全局中只有一個(gè)實(shí)例
D：連接數(shù)據(jù)庫(kù)的功能通常用單例模式實(shí)現(xiàn)

正確答案：C?

答案分析：構(gòu)造函數(shù)設(shè)置為private，僅能確保無(wú)法通過(guò) new 創(chuàng)建新實(shí)例，但仍可以通過(guò) clone、反序列化等方式創(chuàng)建多個(gè)實(shí)例。

5、正則的引擎表述錯(cuò)誤的是？

A 正則引擎主要可以分為兩大類：一種是DFA，一種是NFA。
B 一般而論，NFA引擎則搜索更快一些。但是DFA以表達(dá)式為主導(dǎo)，更容易操縱，因此一般程序員更偏愛(ài)DFA引擎！
C NFA表達(dá)式主導(dǎo),DFA文本主導(dǎo).
D 可以使用是否支持忽略優(yōu)先量詞和分組捕獲來(lái)判斷引擎類型：支持 NFA,不支持 DFA

正確答案：B

答案分析：正確的說(shuō)法應(yīng)該是：一般而論，DFA引擎則搜索更快一些。但是NFA以表達(dá)式為主導(dǎo)，更容易操縱，因此一般程序員更偏愛(ài)NFA引擎！

6、方框中的正則表達(dá)式能與以下哪些選項(xiàng)匹配？

/.123d/

A. **123
B. ****1234
C. 1234
D.123

正確答案：B

答案分析：本題的要點(diǎn)是理解這個(gè)正則表達(dá)式的含義——從左往右，首先是零個(gè)或多個(gè)任意字符（.），跟著是一個(gè)星號(hào)（），然后是 123，最后是一個(gè)數(shù)字。因此答案是B。

7、如下關(guān)于數(shù)據(jù)庫(kù)的說(shuō)法，哪個(gè)是錯(cuò)誤的？

A：為了效率數(shù)據(jù)庫(kù)可以有多個(gè)讀庫(kù)
B：數(shù)據(jù)庫(kù)可以用主從做熱備
C：數(shù)據(jù)庫(kù)不能提供多主多從架構(gòu)
D: 數(shù)據(jù)庫(kù)主從是通過(guò)日志同步的

正確答案：C

答案分析：?數(shù)據(jù)庫(kù)可以提供多主多從架構(gòu)。

8、下面哪個(gè)不是XSS漏洞的修復(fù)方式？

A:對(duì)參數(shù)進(jìn)行htmlspecialchas過(guò)濾
B:對(duì)參數(shù)使用白名單過(guò)濾
C:不允許輸入的內(nèi)容顯示到瀏覽器
D:禁止在js標(biāo)簽內(nèi)輸出用戶輸入的內(nèi)容

正確答案：A?

答案分析：這類過(guò)濾可以解決尖括號(hào)類型的xss，無(wú)法解決js標(biāo)簽內(nèi)的xss

9、下列哪一項(xiàng)不是PHP SAPI模式？

A.ISAPI
B.CGI
C.FastCGI
D.RESTFUL APi

正確答案：D

答案分析：A~C是最常用的模式，D是一種接口的組織方式。

10、對(duì)一個(gè)大文件進(jìn)行逐行遍歷，如下方法性能較高的是？

A：寫一個(gè)實(shí)現(xiàn)了IteratorAggregate 接口的類，通過(guò)該類使用foreach遍歷。
B：使用file_get_contents 將文件內(nèi)容一次性載入內(nèi)存，然后逐行遍歷。
C：通過(guò)exec函數(shù)，調(diào)用shell 工具遍歷
D：使用別人寫的類庫(kù)

正確答案：A

答案分析：使用 IteratorAggregate 可將文件打開后通過(guò)移動(dòng)指針的方式逐行遍歷，不受文件大小影響。使用 file_get_contents 處理大文件很容易導(dǎo)致PHP內(nèi)存溢出；調(diào)用exec 會(huì)產(chǎn)生額外的進(jìn)程，影響性能；其他人寫的類庫(kù)質(zhì)量不一定高。

11、如下選項(xiàng)，哪個(gè)不是設(shè)計(jì)模式應(yīng)該遵循的原則？

A：組合優(yōu)于繼承
B：針對(duì)接口編程
C：盡可能降低耦合
D：盡量使用高性能的語(yǔ)法

正確答案：D
答案分析：設(shè)計(jì)模式的關(guān)注點(diǎn)在于代碼的可維護(hù)性和可復(fù)用性，D選項(xiàng)不是設(shè)計(jì)模式關(guān)注的要點(diǎn)。

12、下列關(guān)于回溯的表達(dá)式錯(cuò)誤的是？

A ab.lmn 匹配 abcdeflmnghijklmn 中的 abcdeflmnghijklmn
B ab.?lmn 匹配 abcdeflmnghijklmn 中的 abcdeflmn
C ab??c 匹配 abcdeflmnghijklmn 中的 abc
D .*lmn 匹配 abcdeflmnghijklmn 中的 abcdeflmn

正確答案：D

答案分析：D是貪婪匹配，所以應(yīng)該匹配到的結(jié)果是abcdeflmnghijklmn

13、函數(shù)中如果使用了try catch finally 語(yǔ)法結(jié)構(gòu)，return 應(yīng)該寫在哪兒？

A：finally 中
B：try 中
C：catch 中
D：任意位置

正確答案：A

答案分析：try 中 return 后 finally 會(huì)繼續(xù)執(zhí)行，如果 finally 中也有return，則最終返回值為 finally 中 return 的值。

14、以下關(guān)于NOSQL的說(shuō)法，不對(duì)的是：

A: Redis支持字符串、哈希、列表、集合、有序集合等數(shù)據(jù)結(jié)構(gòu)，目前Redis不支持事務(wù)。
B: MongoDB支持CAP定理中的AP，MySQL支持CAP中的CA，全部都支持不可能存在。
C: MongoDB不用先創(chuàng)建Collection的結(jié)構(gòu)就可以直接插入數(shù)據(jù)，目前MongoDB不支持事務(wù)。
D: Memcache既支持TCP協(xié)議，也支持UDP協(xié)議，我們可以把PHP的Session存放到Memcache中。

正確答案：A

答案分析：Redis支持事務(wù)。

15、Innodb 鎖機(jī)制說(shuō)法錯(cuò)誤的是？

A：Innodb提供了表鎖與行鎖兩種鎖機(jī)制
B：Innodb的表鎖所會(huì)在表變更的時(shí)候觸發(fā)
C：Innodb下update時(shí)會(huì)自動(dòng)給涉及到的行加上排他鎖，并創(chuàng)建出一個(gè)鏡像副本， 此時(shí)進(jìn)行select 時(shí)查詢的是鏡像副本的數(shù)據(jù)
D：Innodb行鎖狀態(tài)下讀不受影響，寫會(huì)受影響（涉及到的數(shù)據(jù)）

正確答案：A

16、下列哪個(gè)是創(chuàng)建一個(gè)每周三01:00~04:00每3分鐘執(zhí)行執(zhí)行一次的crontab指令？

A： 1,4 3 /bin/bash /home/sijiaomao/ok.sh
B：/3 1,4 3 /bin/bash /home/sijiaomao/ok.sh
C：/3 1-4 3 /bin/bash /home/sijiaomao/ok.sh
D：/3 1-4 * /bin/bash /home/sijiaomao/ok.sh

正確答案：C

答案分析：A：每周三的1時(shí)4時(shí)每分鐘執(zhí)行一次 B：每周三的1時(shí)4時(shí)每3分鐘執(zhí)行一次 C：滿足要求 D：每天的1時(shí)4時(shí)每3分鐘執(zhí)行一次

17、在拆分之前，系統(tǒng)中很多列表和詳情頁(yè)所需的數(shù)據(jù)是可以通過(guò)sql join來(lái)完成的。而拆分后，數(shù)據(jù)庫(kù)可能是分布式在不同實(shí)例和不同的主機(jī)上，join將變得非常麻煩。下面哪種方法不能有效解決這個(gè)問(wèn)題？

A 全局表,系統(tǒng)中所有模塊都可能會(huì)依賴到的一些表在各個(gè)庫(kù)中都保存。
B 字段冗余,“訂單表”中保存“賣家Id”的同時(shí)，將賣家的“Name”字段也冗余，這樣查詢訂單詳情的時(shí)候就不需要再去查詢“賣家用戶表”。
C 主從復(fù)制,將數(shù)據(jù)庫(kù)的讀寫分離。
D 數(shù)據(jù)同步,定時(shí)A庫(kù)中的tbl_a表和B庫(kù)中tbl_b關(guān)聯(lián)，可以定時(shí)將指定的表做主從同步。

正確答案：C

答案分析：主從復(fù)制,將數(shù)據(jù)庫(kù)的讀寫分離。只能擴(kuò)容讀并發(fā)，并不能緩解跨庫(kù)join的問(wèn)題。

18、關(guān)于網(wǎng)絡(luò)IO模型，下列哪一項(xiàng)是正確的？

A.Select比Epoll更快
B.nginx使用的是select模型
C.apache支持select和epoll兩種方式的切換
D.epoll能支持更大的并發(fā)

正確答案：D

答案分析：A epoll更快一些。B nginx使用epoll模型。C apache只支持select

19、PHP執(zhí)行的時(shí)候有如下執(zhí)行過(guò)程：Scanning(Lexing) - Compilation - Execution - Parsing，其含義分別為：

A：將PHP代碼轉(zhuǎn)換為語(yǔ)言片段(Tokens)、將Tokens轉(zhuǎn)換成簡(jiǎn)單而有意義的表達(dá)式、將表達(dá)式編譯成Opocdes、順次執(zhí)行Opcodes
B：將PHP代碼轉(zhuǎn)換為語(yǔ)言片段(Tokens)、將Tokens轉(zhuǎn)換成簡(jiǎn)單而有意義的表達(dá)式、順次執(zhí)行Opcodes、將表達(dá)式編譯成Opocdes
C：將PHP代碼轉(zhuǎn)換為語(yǔ)言片段(Tokens)、將表達(dá)式編譯成Opocdes、順次執(zhí)行Opcodes、將Tokens轉(zhuǎn)換成簡(jiǎn)單而有意義的表達(dá)式
D：將PHP代碼轉(zhuǎn)換為語(yǔ)言片段(Tokens)、將表達(dá)式編譯成Opocdes、將Tokens轉(zhuǎn)換成簡(jiǎn)單而有意義的表達(dá)式、順次執(zhí)行Opcodes

正確答案：C

答案分析：正確答案為C，正確的順序?yàn)椋篠canning(Lexing)、Parsing、Compilation、Execution