直接上**,總共兩個檔案:
common.lua
local _m = {}
local bucket = {}
function
_m.add
(key)
bucket[key] = key
endfunction
_m.get
() return bucket
endreturn _m
index.lua
local common = require
"path.to.common"
-- 載入common檔案,路徑根據實際情況填寫
math.randomseed(ngx.now())
local key = tostring(math.random(1, 100)) -- 生成乙個隨機數字
common.add(key)
local bucket = common.get()
print(cjson.encode(bucket) .. "\n")
ngx.exit(200)
接著,確保nginx.conf開啟了lua快取:
lua_code_cache on;
第一次請求執行index.lua輸出:
第二次請求執行index.lua輸出:
看到沒?第二次執行index.lua的時候,第一次執行時新增的元素28仍然在bucket
變數裡,說明第一次對bucket
變數的修改影響到了第二次的執行,說明不同的請求是共用乙個bucket
變數的。
關於這個問題,是由於require()
函式在第一次載入 common 模組的時候會把它快取在package.loaded
這個全域性表中(當然,這個表其實也不是全域性變數,而是註冊在 lua registry 裡),而lua registry是在vm內共享的,所以也導致了common模組在vm內共享。
而在openresty裡,乙個worker共用乙個vm,所以就出現了同個worker裡的請求都共用了common模組。
如果在開發中不注意這個問題,可能會帶來不可預料的後果,因此,在模組內放置的變數,最好是弄成唯讀,不要試圖去修改它們。
相關資料:
javascript 變數共佔記憶體問題
var a 5 var b a b 1 console.log b 得到6 console.log a 得到5在基本資料型別上 賦值的時候只是值得複製 var a 1,2,3,4 var b a b.push 4 console.log b 得到 1,2,3,4 console.log a 得到 1...
python 併發程式設計 04 多程序間的記憶體共享
匯入 from multiprocessing import manager 例項化 m manager num m.dict num m.list 1,2,3 程式示例 from multiprocessing import manager,process def fun num num 0 0 ...
共模扼流圈
因此,當2個線圈的繞轉方向發生錯亂時,往往會產生相反的效果。如圖5的上半部分所示,當等價電路上的黑點與線圈處於同一側時,磁力結合作為共模扼流圈發揮作用,如下半部分所示,當等價電路上的黑點處於線圈的另一側時,磁力結合將不再作為共模扼流圈發揮作用。可見,黑點位置表示每個線圈的磁力結合方向,並不意味著有黑...