enq: TX - allocate ITL entry等待事件深入剖析

IT那活兒發布于2023-01-11 13:20 / 3863人閱讀

點擊上方“IT那活兒”，關注后了解更多精彩內容！！！

系統配置

oracle數據庫 12.2的雙節點RAC ，操作系統：AIX Version 7.2

DB patch ：

25294150;

25319173;

29314424;OCW APR 2019 RELEASE UPDATE 12.2.0.1.190416 (29314424)

29314339;Database Apr 2019 Release Update : 12.2.0.1.190416 (29314339)

其他信息暫不統計。

現象分析

節點2在2021-09-01 14:03:39出現異常等待事件enq: TX - allocate ITL entry

等待事件分析

依據等待事件 enq: TX - allocate ITL entry 分析來自Doc ID 1472175.1

導致原因：

默認情況下，表的 INITRANS 值為 1，索引的值為 2。這定義了一個稱為感興趣交易列表 (ITL) 的內部塊結構。為了修改一個塊中的數據，一個進程需要使用一個空的ITL槽來記錄該事務有興趣修改該塊中的一些數據。如果空閑 ITL 插槽不足，則將在塊中保留的空閑空間中使用新插槽。如果這用完并且太多并發 DML 事務正在競爭同一個數據塊，我們會觀察到針對以下等待事件的爭用 - “enq：TX - 分配 ITL 條目”。

ITL原理:

ITL(Interested Transaction List)是Oracle數據塊內部的一個組成部分，用來記錄該塊所有發生的事務，一個itl可以看作是一個記錄，在一個時間，可以記錄一個事務（包括提交或者未提交事務）。當然，如果這個事務已經提交，那么這個itl的位置就可以被反復使用了，因為itl類似記錄，所以，有的時候也叫itl槽位。Oracle的每個數據塊中都有一個或者多個事務槽，每一個對數據塊的并發訪問事務都會占用一個事務槽。表和索引的事務槽ini_trans是1、max_trans是255，在oracle10g中，不能修改max_trans這個參數，因為oracle10g忽略了這個參數。如果一個事務一直沒有提交，那么，這個事務將一直占用一個itl槽位，itl里面記錄了事務信息，回滾段的嵌入口，事務類型等等。如果這個事務已經提交，那么，itl槽位中還保存的有這個事務提交時候的SCN號。如dump一個塊，就可以看到itl信息：

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0006.002.0000158e 0x0080104d.00a1.6e --U- 734 fsc 0x0000.6c9deff0
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000

如在并發量特別大的系統中，最好分配足夠的itl個數（10g之前的版本），其實它并浪費不了太多的空間，或者，設置足夠的pctfree，保證itl能擴展，但是pctfree有可能是被行數據給消耗掉的，如update可能一下占滿塊空間，所以，也有可能導致塊內部的空間不夠而導致itl等待，所以在通常情況下，10g版本后引起itl等待的原因往往是因為塊的空間不足導致，并不是tran事務槽數量不足，在正常情況下2k的數據塊最多可以擁有41個itl，4k數據塊最多擁有83，8k最多用友169個itl（以itl 24byte為單位）。INITRANS不足的問題不會出現在索引數據塊上，當發現沒有足夠空間分配ITL slot時，無論是枝點塊還是葉子塊，數據塊會發生分裂(Index Block Split)。

有一種特殊情況也會引起ITL的等待，就是在索引上的遞歸事務itl爭用，這種情況比較特殊。在索引的枝節點上，有且只有一個ITL slot，它是用于當發生節點分裂的遞歸事務(Recursive Transaction)。在葉子節點上，第一條ITL Slot也是用于分裂的遞歸事務的。在一個用戶事務中，如果發生多次分裂，每一次分裂都是由一個多帶帶的遞歸事務控制的，如果下層節點分裂導致其父節點分裂，它們的分裂則由同一個遞歸事務控制。當2個事務同時需要分裂一個枝節點或者葉子節點時，或者枝節點下的2個子節點分別被2個事務分裂，就會造成這種ITL等待。

此問題的主要解決方案是通過重新創建表或索引并更改 INITRANS 或 PCTFREE 參數來增加表或索引的 ITL 功能，以便能夠處理更多并發事務。這反過來將有助于減少“enq：TX - 分配 ITL 條目”等待事件。

實驗論證

實驗一：

數據塊上的initrans不能擴展分配slot導致的itl爭用測試。

數據塊沒有空間留給itl slot擴展時候的測試，創建表luda，指定pctfree為0，同時指定initrans為1然后填滿相關數據塊，再對塊滿的數據進行更新模擬出itl的等待。

1. 創建表luda，并指定pctfree為0，initrans為1

create table luda(a int) pctfree 0 initrans 1;
Table created.

2. 向表中插入數據

idle 06:51:17> begin
for i in 1..20000 loop
insert into luda values(i);
end loop;
end;
/ 2    3    4    5    6

PL/SQL procedure successfully completed.

commit ;


select f,b,count(*) from (select dbms_rowid.rowid_relative_fno(rowid) f,dbms_rowid.rowid_block_number(rowid) b from luda) group by f,b order by 3;

F B COUNT(*)
---------- ---------- ----------
1 94028 182
1 94026 734
1 94017 734
1 94021 734
1 94023 734
1 93997 734
1 93998 734
1 94014 734
1 94024 734
1 93995 734
1 94025 734
1 94016 734
1 94009 734
1 94012 734
1 94015 734
1 93994 734
1 93999 734
1 94008 734
1 94019 734
1 94011 734
1 94018 734
1 94027 734
1 93993 734
1 94013 734
1 94020 734
1 94022 734
1 93996 734
1 94010 734

插入數據后可以發現該表有28個數據塊，填滿了除了94028塊意外的其他數據塊。

3. 導出已經填滿的數據塊93997.

alter system dump datafile 1 block 93997;

Block header dump: 0x00416f2d
Object id on Block? Y
seg/obj: 0x15b03 csc: 0x00.304755 itc: 2 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0001.020.0000033c 0x00c0008a.00de.2d --U- 734 fsc 0x0000.00304794
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
bdba: 0x00416f2d

//發現initrans為1的情況下默認是有2個事務槽，itc=2

data_block_dump,data header at 0x7f7c688a4a5c
===============
tsiz: 0x1fa0
hsiz: 0x5ce
pbl: 0x7f7c688a4a5c
76543210
flag=--------
ntab=1
nrow=734
frre=-1
fsbo=0x5ce
fseo=0xb95
avsp=0x4
tosp=0x4
0xe:pti[0] nrow=734        offs=0
0x12:pri[0] offs=0x1f99
0x14:pri[1] offs=0x1f92
0x16:pri[2] offs=0x1f8b
0x18:pri[3] offs=0x1f84
0x1a:pri[4] offs=0x1f7d
0x1c:pri[5] offs=0x1f76
0x1e:pri[6] offs=0x1f6f
0x20:pri[7] offs=0x1f68
0x22:pri[8] offs=0x1f61
0x24:pri[9] offs=0x1f5a
0x26:pri[10] offs=0x1f53
0x28:pri[11] offs=0x1f4c
0x2a:pri[12] offs=0x1f45
0x2c:pri[13] offs=0x1f3e
0x2e:pri[14] offs=0x1f37
0x30:pri[15] offs=0x1f30
0x32:pri[16] offs=0x1f29
0x34:pri[17] offs=0x1f22
0x36:pri[18] offs=0x1f1b
0x38:pri[19] offs=0x1f14
0x3a:pri[20] offs=0x1f0d
0x3c:pri[21] offs=0x1f06
0x3e:pri[22] offs=0x1eff
0x40:pri[23] offs=0x1ef8
0x42:pri[24] offs=0x1ef1
0x44:pri[25] offs=0x1eea
0x46:pri[26] offs=0x1ee3
0x48:pri[27] offs=0x1edc
0x4a:pri[28] offs=0x1ed5
0x4c:pri[29] offs=0x1ece
0x4e:pri[30] offs=0x1ec7
0x50:pri[31] offs=0x1ec0
0x52:pri[32] offs=0x1eb9
0x54:pri[33] offs=0x1eb2
0x56:pri[34] offs=0x1eab
0x58:pri[35] offs=0x1ea4
0x5a:pri[36] offs=0x1e9d
0x5c:pri[37] offs=0x1e96
0x5e:pri[38] offs=0x1e8f
0x60:pri[39] offs=0x1e88
0x62:pri[40] offs=0x1e81
0x64:pri[41] offs=0x1e7a
0x66:pri[42] offs=0x1e73
0x68:pri[43] offs=0x1e6c
0x6a:pri[44] offs=0x1e65
0x6c:pri[45] offs=0x1e5e
0x6e:pri[46] offs=0x1e57
0x70:pri[47] offs=0x1e50
0x72:pri[48] offs=0x1e49
0x74:pri[49] offs=0x1e42
0x76:pri[50] offs=0x1e3b
0x78:pri[51] offs=0x1e34
0x7a:pri[52] offs=0x1e2d
0x7c:pri[53] offs=0x1e26
0x7e:pri[54] offs=0x1e1f
0x80:pri[55] offs=0x1e18
0x82:pri[56] offs=0x1e11
0x84:pri[57] offs=0x1e0a
0x86:pri[58] offs=0x1e03
0x88:pri[59] offs=0x1dfc
0x8a:pri[60] offs=0x1df5
0x8c:pri[61] offs=0x1dee
0x8e:pri[62] offs=0x1de7
0x90:pri[63] offs=0x1de1
0x92:pri[64] offs=0x1dda
0x94:pri[65] offs=0x1dd3
0x96:pri[66] offs=0x1dcc
0x98:pri[67] offs=0x1dc5
0x9a:pri[68] offs=0x1dbe
0x9c:pri[69] offs=0x1db7
0x9e:pri[70] offs=0x1db0
0xa0:pri[71] offs=0x1da9
0xa2:pri[72] offs=0x1da2
0xa4:pri[73] offs=0x1d9b

4. 塊滿的情況測試slot的分配，根據前面的查詢結果我們知道單個塊的存儲行數為734行，也可以通過dump中的nrow=734得知，所以我們在這部測試中依次更新第100，200，300行的數據。

session 1 更新第100行的數據：

SQL> update luda set a=a where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)= 93997 and 
dbms_rowid.ROWID_ROW_NUMBER(rowid)=100;
1 row updated.

session 2更新第200行的數據：

SQL> update luda set a=a where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)= 93997 and 
dbms_rowid.ROWID_ROW_NUMBER(rowid)=200;

session 3更新第300行的數據，先查看此時的SID，并且在執行過程中session 3 hang住：

SQL> select sid from v$mystat where rownum=1;

SID
----------
172

SQL> update luda set a=a where dbms_rowid.ROWID_BLOCK_NUMBER(rowid)= 93997 and dbms_rowid.ROWID_ROW_NUMBER(rowid)=300;

--此時進程hang住

SQL> select sid,event from v$session where sid=158;

SID EVENT
---------- ----------------------------------------------------------------
172 enq: TX - allocate ITL entry

1 row updated.

此時dump次數據塊：

alter system dump datafile 1 block 93997；

Block header dump: 0x0040ee92
Object id on Block? Y
seg/obj: 0xcb0a csc: 0x00.bb97e itc: 2 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc
0x01   0x0001.020.0000033c 0x00c0008a.00de.2d ---- 1 fsc 0x0000.00304794
0x02   0x0000.000.00000000  0x00000000.0000.00 ---- 1 fsc 0x0000.00000000

--通過此時的dump我們也可以發現原先為被占用的2個事務槽已經被占用而且事務未提交。

data_block_dump,data header at 0xd77645c
===============
tsiz: 0x1fa0
hsiz: 0x5ce
pbl: 0x0d77645c
bdba: 0x0040ee92
76543210
flag=--------
ntab=1
nrow=734
frre=-1
fsbo=0x5ce
fseo=0xbf8
avsp=0x4
tosp=0x4
0xe:pti[0] nrow=734 offs=0

從以上驗證了空間不足的情況下會導致itl無法分配引起enq: TX – allocate ITL entry等待事件的產生。

實驗二：

當一個事務需要修改一個數據塊時，需要在數據塊頭部獲取一個可用的ITL槽，用于記錄事務的id,使用undo數據塊地址,scn等信息。如果事務申請不到新的可用ITL槽時，就會產生enq: TX - allocate ITL entry等待。

發生這個等待時，要么是塊上的已分配ITL個數(通過ini_trans參數控制)達到了上限255(10g以后沒有了max_trans限制參數，無法指定小于255的值)，要么是這個塊中沒有更多的空閑空間來容納一個ITL了(每個ITL占用24bytes)。

默認情況下創建的表ITL槽數最小為1+1,pctfree為10，那么如果是這樣一種情況，如果表中經常執行update語句，然后塊中剩余的10%空間所剩無幾，而且業務的并發量還很大，此時就很容易遇到enq: TX - allocate ITL entry等待。

1. 問題模擬：

create table ttitl as select * from dba_objects;

select t.object_id,t.object_name,dbms_rowid.rowid_relative_fno(t.rowid),dbms_rowid.rowid_block_number(t.rowid) from ttitl t where dbms_rowid.rowid_block_number(t.rowid)=143612;

通過幾個更新語句將默認的ITL槽占滿

update ttitl set object_name=xxxxxxxxxxx where object_id=20;
alter system dump datafile 4 block 143612;

我們要拿4號文件的143612塊做實驗，目前塊中擁有92行數據，現在還需要看塊上還存在多少剩余空間? 答案是通過fseo-fsbo或者bbed得到。

fsbo=0xc8 --=======>>>>>>fsbo代表 Free Space Begin offset 空閑 空間的起始偏儀量
fseo=0x342 --=======>>>>>>fseo代表Free Space End offset 空閑空間的結束偏儀量
0x342-0xc8=0x27A
834-200=634

產生一個事務后

fsbo=0xc8
fseo=0x32a
0x32a-0xc8=0x262=610
634-610=24bytes

也正驗證了一個itl槽占24bytes的說法

按照這個方式計算，這個塊上還能夠存在很多事務，610/24=25,該塊上還能增加25個事務呢
現在通過update方式將塊上的空閑空間縮小

update ttitl set 
object_name=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
where object_id>60;

現在通過BBED和重新dump該塊發現此塊空閑空間已經只剩19bytes了。

[oracle@test ~]$ cat par.txt
blocksize=8192
listfile=filelist.txt
mode=edit
[oracle@test ~]$ cat filelist.txt
1 /u01/app/oracle/oradata/orcl/system01.dbf 933232640
2 /u01/app/oracle/oradata/orcl/mctpsys.dbf 10485760
3 /u01/app/oracle/oradata/orcl/sysaux01.dbf 618659840
4 /u01/app/oracle/oradata/orcl/users01.dbf 2246574080
5 /u01/app/oracle/oradata/orcl/example01.dbf 104857600
6 /u01/app/oracle/oradata/orcl/users02.dbf 52428800
7 /u01/app/oracle/oradata/orcl/mgmt.dbf 1363148800
8 /u01/app/oracle/oradata/orcl/mgmt_deepdive.dbf 209715200
9 /u01/app/oracle/oradata/orcl/mgmt_ecm_depot1.dbf 41943040
10 /u01/app/oracle/oradata/orcl/EPMRANGE1.dbf 6442450944
11 /u01/app/oracle/oradata/orcl/EPMIDX.dbf 4294967296
12 /u01/app/oracle/oradata/orcl/EPMDAT1.dbf 209715200
13 /u01/app/oracle/oradata/orcl/undotbs02.dbf 5368709120
14 /u01/app/oracle/oradata/orcl/mctpsys1.dbf 314572800
15 /u01/app/oracle/oradata/orcl/mctpsys2.dbf 1073741824
16 /u01/app/oracle/oradata/orcl/rmantbs.dbf 209715200
17 /u01/app/oracle/oradata/orcl/ggs1.dbf 524288000
18 /u01/app/oracle/oradata/orcl/ZZZ1.DBF 20971520
[oracle@test ~]$ bbed parfile=par.txt
Password: blockedit

BBED> set dba 4,143612
     DBA 0x010230fc (16920828 4,143612)

BBED> map
File: /u01/app/oracle/oradata/orcl/users01.dbf (4)
Block: 143612                                Dba:0x010230fc
------------------------------------------------------------
KTB Data Block (Table/Cluster)

struct kcbh, 20 bytes @0 

struct ktbbh, 120 bytes @20 

struct kdbh, 14 bytes @148 

struct kdbt[1], 4 bytes @162 

sb2 kdbr[91] @166 

ub1 freespace[19] @348 --====>>>>>>>>>>>>>塊上的空閑空間為19bytes 

ub1 rowdata[7821] @367 

ub4 tailchk @8188

--摘自datafile dump日志

fsbo=0xc8
fseo=0xdb
0xdb-0xc8=0x13=19

這塊上只有19bytes字節的空間了，看來是無法再容納一個ITL槽了，再新產生一個事務

update ttitl set object_name=I_FILE1 where object_id=41;

此時可以看到enq: TX - allocate ITL entry等待，直至塊上的其它事務提交或回滾后，此會話才能繼續，否則一直處于等待狀態。

SQL> select sid,serial#,status,username,event,seconds_in_wait,sql_id from v$session where serial#<>1 and sql_id is not null and event not like %SQL*Net message% and event not like Streams AQ% order by 7;

       SID    SERIAL# STATUS   USERNAME   EVENT                        SECONDS_IN_WAIT SQL_ID
---------- ---------- -------- ---------- ---------------------------------------- --------------- -------------
       528     39292 ACTIVE   TT       enq: TX - allocate ITL entry                    4 512zw5fc3bztt

--記錄一下enq鎖的p1 p2 p3值的含義

select * from v$session where event like enq%;
EVENT# 189
EVENT enq: TX - allocate ITL entry
P1TEXT name|mode
P1 1415053316
P1RAW 0000000054580004
P2TEXT usn<<16 | slot
P2 131084
P2RAW 000000000002000C
P3TEXT sequence
P3 88864
P3RAW 0000000000015B20

--P1值與鎖名稱和鎖模式有關1415053316轉換成16進制后為54580004,其中54代表字母T,58代表字母X,合一起就是鎖的name。

SQL> select dump(T,16),dump(X,16) from dual;

DUMP(T,16) DUMP(X,16)
---------------- ----------------
Typ=96 Len=1: 54 Typ=96 Len=1: 58

--P1值的后4位0004代表申請鎖的模式

SQL> select * from v$lock where sid=528;

ADDR KADDR SID TYPE ID1 ID2 LMODE REQUEST CTIME BLOCK
---------------- ---------------- ---------- ---- ---------- ---------- ---------- ---------- ---------- ----------
00000000DEC35368 00000000DEC35388 528 TX 131084      88864          0          4        129          0
00000000DD5099A8 00000000DD5099D0 528 TM 1519283          0          3          0       1294          0

--P2和P3值與事務相關，比如上面的P2值131084代表XIDUSN和XIDSLOT，

select 131084/45536 as usn,round(mod(131084,45536)) slot from dual;

--P3值88864代表xidsqn

ADDR XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK UBASQN UBAREC STATUS START_TIME START_SCNB START_SCNW START_UEXT START_UBAFIL START_UBABLK START_UBASQN START_UBAREC SES_ADDR FLAG SPACE RECURSIVE NOUNDO PTX NAME PRV_XIDUSN PRV_XIDSLT PRV_XIDSQN PTX_XIDUSN PTX_XIDSLT PTX_XIDSQN DSCN-B DSCN-W USED_UBLK USED_UREC LOG_IO PHY_IO CR_GET CR_CHANGE START_DATE DSCN_BASE DSCN_WRAP START_SCN DEPENDENT_SCN XID PRV_XID PTX_XID
---------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------------- -------------------- ---------- ---------- ---------- ------------ ------------ ------------ ------------ ---------------- ---------- ----- --------- ------ --- -------------------------------------------------------------------------------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------- ---------- ---------- ---------- ------------- ---------------- ---------------- ----------------
00000000DD61F730 6         29      74079         19       9504      19040         51 ACTIVE 04/20/15 10:30:56    3585075880       2902         18           19         9504        19040           51 00000000DF221CA0 7683 NO    NO        NO     NO                                                                                            0          0          0          0          0          0          0   &

對于ITL事務槽來說，除去其初始分配的事務槽（可以理解為固定存在的事務槽），在一個BLOCK寫滿的情況下，繼續擴展ITL事務槽需要占用PCTFREE參數指定的預留空間。例如PCTFREE值設定為10%，而一個塊的大小是8KB也就是8192B，則預留的空間約為819.2B，而一個ITL事務槽的大小為24B（ITL事務槽大小參考文獻，最開始查看一些文章有說大小是46B的，但是實際測試不相符），由此我們可以大致推斷其最多可擴展的ITL事務槽數量。而在實際生產環境中，update語句更新該數據塊中的字段，使其字段長度增加，也會占用PCTFREE預留空間,導致ITL事務槽的可擴展數量減少。

從根本上來說enq: TX - allocate ITL entry等待事件的產生是由于當前BLOCK沒有足夠的空間去擴展事務槽，或者由于多個長事務導致的ITL事務槽長時間占用，從而引起事務槽爭用。

2. 一般常用解決辦法：

Increase INITRANS

1) Depending on the number of transactions in the table we need to alter the value of INITRANS. here it has been changed to 50:

alter table INITRANS 50;

2) Then re-organize the table using move (alter table move;)

3) Then rebuild all the indexes of this table as below

alter index rebuild INITRANS 50;

Increase PCTFREE

If the issue is not resolved by increasing INITRANS then try increasing PCTFREE. Increasing PCTFREE holds more space back and so spreads the same number of rows over more blocks. This means that there are more ITL slots available, overall.

1) Spreading rows into more number of blocks will also helps to reduce this wait event.

alter table

PCTFREE 20;

2) Then re-organize the table using move (alter table move;)

3) Rebuild index alter index index_name rebuild PCTFREE 20;

A Combination of increasing both INITRANS and PCTFREE

1) Set INITRANS to 50 and pct_free to 20 alter table PCTFREE 20 INITRANS 50;

2) Re-organize the table using move (alter table move;)

3) Then rebuild all the indexes of the table as below alter index rebuild PCTFREE 20 INITRANS 50;

END

更多精彩干貨分享

點擊下方名片關注

IT那活兒

GPU云服務器云服務器深入剖析nginx 等待事件 entries allocate

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129748.html

Oracle數據庫4031故障分析

Oracle數據庫4031故障分析 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; m...

不知名網友 2023-01-11 11:02 評論0 收藏2316
AbstractQueuedSynchronizer原理剖析

摘要：無論是公平鎖還是非公平鎖，它們的實現都依賴于，它提供了一個基于先進先出等待隊列實現和的框架。特性如下僅通過一個類型來代表狀態。等喚醒的時候，重新獲取鎖，并清掉中的線程。無論是公平鎖還是非公平鎖，它們的實現都依賴于AbstractQueuedSynchronizer，它提供了一個基于先進先出等待隊列實現block locks和synchronizers的框架。特性如下僅通過一個 ...

vslam 2019-08-16 13:50 評論0 收藏0
原理剖析（第 005 篇）AQS工作原理分析

摘要：等到所有子線程都執行完后即，會主調用線程，然后主調用線程就會從函數返回，繼續后余動作。原理剖析（第 005 篇）AQS工作原理分析 - 一、大致介紹 1、前面章節講解了一下CAS，簡單講就是cmpxchg+lock的原子操作； 2、而在談到并發操作里面，我們不得不談到AQS，JDK的源碼里面好多并發的類都是通過Sync的內部類繼承AQS而實現出五花八門的功能； 3、本章節就和大家分享...

Aklman 2019-08-16 11:12 評論0 收藏0
(PHP7內核剖析-10) 線程安全

摘要：中專門為解決線程安全的問題抽象出了一個線程安全資源管理器，實現原理比較簡單既然共用資源這么困難那么就干脆不共用，各線程不再共享同一份全局變量，而是各復制一份，使用數據時各線程各取自己的副本，互不干擾。 1.線程安全資源管理器 PHP的SAPI多數是單線程環境，比如cli、fpm、cgi，每個進程只啟動一個主線程，這種模式下是不存在線程安全問題的，但是也有多線程的環境，比如Apache，...

Achilles 2019-06-28 18:43 評論0 收藏0