首頁 >後端開發 >php教程 >怪異的可怕php

怪異的可怕php

William Shakespeare
William Shakespeare原創
2025-02-25 09:25:08597瀏覽

Spooky Scary PHP

準備好南瓜糖和蘋果酒了嗎?一年一度的萬聖節又到了!雖然全球各地慶祝萬聖節的狂熱程度不及美國,但我還是想分享一些“恐怖”的PHP技巧來慶祝這個節日。這篇文章輕鬆有趣,將向您展示PHP自身的一些令人驚訝(但合乎邏輯)的行為,以及一些人利用PHP完成任務時那些令人毛骨悚然(且可能非常不合邏輯)的方法。您可以把它看作我的節日禮物,一點程序員的“精神糖果”——畢竟,為什麼只有不給糖就搗蛋的小朋友才能享用所有美味呢?

要點總結

  • PHP可能會表現出意想不到的行為,例如在第一個foreach循環之外保留引用,導致輸出結果出乎意料。可以通過使用數組的鍵將字符串重新賦值來緩解這個問題。
  • 當使用PHP執行更複雜的任務(例如shell腳本)時,理解在fork時執行環境是如何克隆的,以及各種資源如何在所有進程中受到影響至關重要。例如,連接數據庫時,最好在fork子進程後在父進程中連接,子進程如有需要則自行連接。
  • 單例模式(實際上只不過是花哨的面向對象全局變量)會使調試變得困難。建議盡可能避免使用單例模式。
  • 雖然像“Spooky Scary PHP”這樣的非常規編碼實踐很有趣且具有教育意義,但它們通常不被認為是編寫生產代碼的良好實踐,因為它們通常涉及使用效率低下、不清楚或不可預測的函數或技術。

鬧鬼的數組

從前,在一個不那麼遙遠的開發工作室裡,亞瑟深夜還在編寫代碼。他不知道自己即將使用的數組鬧鬼了!每敲擊一次鍵盤,他都感到一陣寒意從脊椎滑落,但他愚蠢地忽略了這種微妙的預感。

<code class="language-php"><?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
foreach ($spell as $word) {
    echo $word . "n";
}</code>

好吧,這個數組並沒有真正鬧鬼,但輸出結果確實出乎意料:

<code>Double
Toil
Trouble
Cauldron
Cauldron</code>

這種“恐怖”行為的原因在於PHP如何在第一個foreach循環之外保留引用。當第二個循環開始時,$word仍然是引用,指向數組的最後一個元素。第二個循環的第一次迭代將“double”賦值給$word,這覆蓋了最後一個元素。第二次迭代將“toil”賦值給$word,再次覆蓋最後一個元素。當循環讀取最後一個元素的值時,它已經被多次覆蓋了。要深入了解這種行為,我建議閱讀Johannes Schlüter關於這個主題的博客文章,“References and foreach”。您還可以運行這個稍微修改過的版本並檢查其輸出,以便更好地了解PHP正在做什麼:

<code class="language-php"><?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
foreach ($spell as $word) {
    echo $word . "n";
}</code>

亞瑟那天晚上吸取了一個非常重要的教訓,並使用數組的鍵將字符串重新賦值來修復了他的代碼:

<code>Double
Toil
Trouble
Cauldron
Cauldron</code>

幽靈數據庫連接

PHP越來越多的被要求不僅僅是每天生成網頁。用PHP編寫的shell腳本數量正在增加,這些腳本執行的任務也越來越複雜,因為開發人員看到了整合開發語言的優點。通常情況下,這些腳本的性能是可以接受的,為了方便而進行的權衡是可以證明的。因此,蘇珊正在編寫一個並行處理任務,其代碼類似於以下代碼:

<code class="language-php"><?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
var_dump($spell);
foreach ($spell as $word) {
    echo join(" ", $spell) . "n";
}</code>

她的代碼fork了子進程來並行執行一些長時間運行的工作,而父進程繼續監控子進程,並在所有子進程終止時報告結果。

<code class="language-php"><?php
foreach ($spell as $key => $word) {
    $spell[$key] = ucfirst($word);
}</code>

然而,蘇珊的領導要求她將狀態信息記錄到日誌中,而不是輸出到標準輸出。蘇珊使用已經包含在公司代碼庫中的單例模式PDO數據庫連接機制擴展了她的代碼。

<code class="language-php">#! /usr/bin/env php
<?php
$pids = array();
foreach (range(0, 4) as $i) {
    $pid = pcntl_fork();
    if ($pid > 0) {
        echo "Fork child $pid.n";
        // record PIDs in reverse lookup array
        $pids[$pid] = true;
    } else if ($pid == 0) {
        echo "Child " . posix_getpid() . " working...n";
        sleep(5);
        exit;
    }
}
// wait for children to finish
while (count($pids)) {
    $pid = pcntl_wait($status);
    echo "Child $pid finished.n";
    unset($pids[$pid]);
}
echo "Tasks complete.n";</code>

蘇珊期望看到timings表中的行被更新;“start time”行應該列出整個進程啟動的時間戳,“stop time”行應該列出所有進程完成的時間戳。不幸的是,執行拋出了異常,數據庫沒有反映她的預期。

<code>Fork child 1634.
Fork child 1635.
Fork child 1636.
Child 1634 working...
Fork child 1637.
Child 1635 working...
Child 1636 working...
Fork child 1638.
Child 1637 working...
Child 1638 working...
Child 1637 finished.
Child 1636 finished.
Child 1638 finished.
Child 1635 finished.
Child 1634 finished.
Tasks complete.</code>
<code class="language-php">#! /usr/bin/env php
<?php
$db = Db::connection();
$db->query("UPDATE timings SET tstamp=NOW() WHERE name='start time'");

$pids = array();
foreach (range(0, 4) as $i) {
    ...
}
while (count($pids)) {
    ...
}

$db->query("UPDATE timings SET tstamp=NOW() WHERE name='stop time'");

class Db
{
    protected static $db;

    public static function connection() {
        if (!isset(self::$db)) {
            self::$db = new PDO("mysql:host=localhost;dbname=test",
                "dbuser", "dbpass");
            self::$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        }
        return self::$db;
    }
}</code>

像亞瑟的數組一樣,蘇珊的數據庫也鬧鬼了嗎?好吧,如果我給你以下線索,看看你能不能把這個謎團拼湊起來:1. 當一個進程fork時,父進程會被複製為子進程。然後,這些複製的進程從那時起並行執行。 2. 靜態成員在類的所有實例之間共享。

PDO連接被包裝為單例,因此應用程序中對它的任何引用都指向內存中的相同資源。 DB::connection()首先返回對象引用,父進程fork,子進程繼續處理,而父進程等待,子進程終止並PHP清理使用的資源,然後父進程嘗試再次使用數據庫對象。連接到MySQL的連接已在子進程中關閉,因此最終調用失敗。在最終日誌記錄查詢之前天真地嘗試再次獲取連接不會幫助蘇珊,因為會返回相同的失效PDO實例,因為它是一個單例。我建議避免使用單例——它們實際上只不過是花哨的面向對象的全局變量,這會使調試變得困難。即使在我們的例子中,連接仍然會被子進程關閉,但如果在第二個查詢之前調用DB::connection(),如果不用單例,它至少會返回一個新的連接。但更好的方法是理解在fork時執行環境是如何克隆的,以及各種資源如何在所有進程中受到影響。在這種情況下,最好在fork子進程後在父進程中連接到數據庫,子進程如有需要則自行連接。連接不應該共享。

<code>PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /home/susanbrown/test.php:21
Stack trace:
#0 /home/susanbrown/test.php(21): PDO->query('UPDATE timers S...')
#1 {main}</code>

弗蘭肯斯坦博士的API

瑪麗·雪萊的《弗蘭肯斯坦》講述的是一個科學家創造生命的故事,但他對其醜陋感到厭惡,於是拋棄了它。在一些不必要的死亡和破壞之後,弗蘭肯斯坦博士追捕他的創造物,直到世界的盡頭,試圖摧毀它。我們許多人都賦予瞭如此醜陋的代碼以生命,以至於我們後來希望自己能逃離它——代碼如此醜陋、如此愚鈍、如此混亂,以至於讓我們想嘔吐,但它只想要愛和理解。幾年前,我一直在玩弄一個關於數據庫接口的想法,以及如果它們更嚴格地遵守Unix的“一切都是文件”的哲學,它們會是什麼樣子:查詢將被寫入“文件”,結果集將從“文件”中讀取。一件事導致另一件事,經過我自己的一些死亡和破壞性編碼之後,我編寫了以下這個與我最初的想法幾乎沒有關係的類:

<code class="language-php"><?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
foreach ($spell as $word) {
    echo $word . "n";
}</code>

結果是天才的,但令人厭惡:一個看起來像對象(沒有真正的API方法)、數組或字符串的實例……

<code>Double
Toil
Trouble
Cauldron
Cauldron</code>

我此後不久寫了一篇博客,並將其標記為邪惡的。看到它的朋友和同事幾乎都做出了同樣的反應:“太棒了!現在把它殺了……用火燒死它。” 但多年以來,我承認我對它有所軟化。它真正違反的唯一規則是程序員對query()result()等平淡無奇的命名方法的期望。相反,它使用查詢字符串本身作為查詢方法,對像是接口,結果集是結果。當然,它並不比過度泛化的ORM接口更糟糕,ORM接口將select()where()方法鏈接在一起,看起來像SQL查詢,但有更多的->。也許我的類並沒有那麼邪惡?也許它只是想被愛?我當然不想死在北極!

結束語

我希望您喜歡這篇文章,並且這些例子不會給您帶來(太多)噩夢!我相信您也有自己關於鬧鬼或可怕代碼的故事,無論您身在何處,都不需要讓節日的樂趣消失,因此請隨時在下面的評論中分享您可怕的PHP故事! 圖片來自Fotolia

(以下為FAQ,已根據原文內容調整和精簡)

關於“Spooky Scary PHP”的常見問題

什麼是“Spooky Scary PHP”?

“Spooky Scary PHP”是一種獨特的PHP編碼方法,它涉及使用非常規或意想不到的方法來實現某些結果。這可能包括使用鮮為人知的函數、利用語言中的特性,甚至使用看起來不應該工作但確實有效的代碼。這是一種有趣且令人興奮的方式,可以探索PHP的深度,並且經常會帶來令人驚訝和啟迪的發現。

如何開始學習“Spooky Scary PHP”?

學習“Spooky Scary PHP”的最佳方法是對PHP基礎知識有紮實的理解。一旦您對基礎知識感到滿意,就可以開始探索該語言更晦澀的角落。閱讀關於“Spooky Scary PHP”的文章、教程和論壇討論也可能非常有幫助。記住,目標不是編寫高效或實用的代碼,而是以更深入的方式探索和理解語言。

“Spooky Scary PHP”是一種好的實踐嗎?

“Spooky Scary PHP”通常不被認為是編寫生產代碼的良好實踐。它通常涉及使用效率低下、不清楚或不可預測的函數或技術。但是,它可能是學習更多關於該語言以及挑戰您對PHP的理解的一種好方法。它更像是一種學習工具和有趣的實驗,而不是一種實用的編碼風格。

“Spooky Scary PHP”有害嗎?

雖然“Spooky Scary PHP”既有趣又有教育意義,但務必負責任地使用它。在“Spooky Scary PHP”中使用的一些技術如果在實時環境中使用,可能會造成危害,例如那些利用語言中的特性或錯誤的技術。務必徹底測試您編寫的任何代碼,並且永遠不要在項目的重要部分使用“Spooky Scary PHP”技術。

以上是怪異的可怕php的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
上一篇:PHP主|例外下一篇:PHP主|例外