در این مطلب، ویدئو python: ضعیف رفر چیست؟ (متوسط - پیشرفته) آنتونی شماره 366 را توضیح می دهد با زیرنویس فارسی را برای دانلود قرار داده ام. شما میتوانید با پرداخت 15 هزار تومان ، این ویدیو به علاوه تمامی فیلم های سایت را دانلود کنید.اکثر فیلم های سایت به زبان انگلیسی می باشند. این ویدئو دارای زیرنویس فارسی ترجمه شده توسط هوش مصنوعی می باشد که میتوانید نمونه ای از آن را در قسمت پایانی این مطلب مشاهده کنید.
مدت زمان فیلم: 00:10:39
تصاویر این ویدئو:
قسمتی از زیرنویس این فیلم:
00:00:02,800 –> 00:00:04,720
سلام و به ویدیوی دیگری در این ویدیو خوش آمدید،
2
00:00:04,720 –> 00:00:06,160
ما در مورد
3
00:00:06,160 –> 00:00:08,639
منابع ضعیف در پایتون
4
00:00:08,639 –> 00:00:10,960
و موارد استفاده از آنها و همچنین
5
00:00:10,960 –> 00:00:12,880
چند چیز کوچک سرگرم کننده در
6
00:00:12,880 –> 00:00:15,440
ماژول گراف ضعیف صحبت خواهیم کرد، اما به هر حال اجازه دهید
7
00:00:15,440 –> 00:00:16,640
وارد آن شویم.
8
00:00:16,640 –> 00:00:18,480
بسیار خوب، بنابراین نکته
9
00:00:18,480 –> 00:00:19,359
10
00:00:19,359 –> 00:00:20,880
اصلی که من در مورد ماژول مرجع ضعیف فکر می کنم این
11
00:00:20,880 –> 00:00:24,400
است که روشی برای دور زدن
12
00:00:24,400 –> 00:00:26,800
شمارش ارجاعات در پایتون um است.
13
00:00:26,800 –> 00:00:28,560
اجازه دهید فقط یک نسخه نمایشی کوتاه از
14
00:00:28,560 –> 00:00:30,080
شمارش مراجع را به شما ارائه دهم تا بتوانید به نوعی
15
00:00:30,080 –> 00:00:32,159
ببینید من درباره چه چیزی صحبت می کنم. در مورد
16
00:00:32,159 –> 00:00:34,239
ما قرار است یک کلاس
17
00:00:34,239 –> 00:00:37,120
بسازیم و به آن یک متد dell می
18
00:00:37,120 –> 00:00:38,800
دهیم، این روشی است که فراخوانی می شود
19
00:00:38,800 –> 00:00:39,680
در حالی
20
00:00:39,680 –> 00:00:41,600
که شیء به طور معمول زباله جمع آوری می شود،
21
00:00:41,600 –> 00:00:43,440
شما خودتان این ها را پیاده سازی نمی کنید
22
00:00:43,440 –> 00:00:45,520
زیرا
23
00:00:45,520 –> 00:00:46,800
می دانید که جمع آوری زباله می تواند
24
00:00:46,800 –> 00:00:47,680
25
00:00:47,680 –> 00:00:49,440
در هر نوع زمانی و واقعاً
26
00:00:49,440 –> 00:00:51,600
قابل پیشبینی نیست،
27
00:00:51,600 –> 00:00:52,800
آنطور که در زبانهای دیگر در مورد آن فکر میکنید، واقعاً مخرب
28
00:00:52,800 –> 00:00:54,239
29
00:00:54,239 –> 00:00:57,680
نیست، اما میدانید که اینطوری کار میکند،
30
00:00:57,680 –> 00:00:59,199
اما بیایید
31
00:00:59,199 –> 00:01:02,559
انجام دهیم، فقط خداحافظی میکنم و خود را انجام میدهم
32
00:01:02,559 –> 00:01:04,319
و اگر یکی از آنها را بسازیم این اشیاء و
33
00:01:04,319 –> 00:01:05,119
عمل می کنند معمولاً میخواهم کمی عجیب و غریب از مفسر را به شما نشان دهم،
34
00:01:05,119 –> 00:01:06,720
من در
35
00:01:06,720 –> 00:01:09,360
واقع یک ویدیوی دیگر در این مورد انجام دادهام،
36
00:01:09,360 –> 00:01:11,360
بنابراین در توضیحات پیوند میدهم
37
00:01:11,360 –> 00:01:13,600
اگر این شی
38
00:01:13,600 –> 00:01:14,640
را بسازیم، فکر میکنید که
39
00:01:14,640 –> 00:01:16,400
پس از این عبارت هیچ ارجاعی به آن وجود نخواهد داشت.
40
00:01:16,400 –> 00:01:18,960
و میدانید زبالهها
41
00:01:18,960 –> 00:01:20,880
فوراً جمعآوری میشوند، اما میبینیم که
42
00:01:20,880 –> 00:01:22,159
این اتفاق نمیافتد، ما
43
00:01:22,159 –> 00:01:23,920
لاستیک را در اینجا چاپ میکنیم و این جسم هنوز زنده است
44
00:01:23,920 –> 00:01:28,320
و دلیل اینکه هنوز زندگی میکند
45
00:01:28,479 –> 00:01:30,880
حداقل در c python یا حداقل در آخرین
46
00:01:30,880 –> 00:01:32,880
مفسر تعاملی است.
47
00:01:32,880 –> 00:01:35,119
عبارت در یک
48
00:01:35,119 –> 00:01:37,119
متغیر زیرخط مخصوص ذخیره می شود و بنابراین شما
49
00:01:37,119 –> 00:01:39,040
می توانید ببینید که این شی در
50
00:01:39,040 –> 00:01:40,320
حال حاضر زنده است، اگر بخواهم
51
00:01:40,320 –> 00:01:42,240
عبارات دیگری مانند یک را ایجاد کنم، خواهید دید
52
00:01:42,240 –> 00:01:44,320
که تعداد ارجاع به صفر می رسد و
53
00:01:44,320 –> 00:01:46,560
زباله های جمع آوری شده را جمع آوری می کند
54
00:01:46,560 –> 00:01:47,920
و برای نشان دادن این کمی
55
00:01:47,920 –> 00:01:50,479
بیشتر اگر این را به یک مقدار نسبت دهیم و
56
00:01:50,479 –> 00:01:52,520
از
57
00:01:52,520 –> 00:01:54,799
sys.getrefcount استفاده کنیم که راهی برای پرسیدن
58
00:01:54,799 –> 00:01:56,960
تعداد ref یک شی است،
59
00:01:56,960 –> 00:01:58,640
خواهید دید که در واقع دو را برمی گرداند که
60
00:01:58,640 –> 00:02:00,320
در اینجا یکی از جالب است.
61
00:02:00,320 –> 00:02:02,159
ارجاعات e این انتساب
62
00:02:02,159 –> 00:02:03,920
در اینجا است، بنابراین این یک مرجع به این
63
00:02:03,920 –> 00:02:06,159
شی است، بنابراین یک refcon نیز دارد، اما
64
00:02:06,159 –> 00:02:07,759
در واقع وقتی آن را به عنوان
65
00:02:07,759 –> 00:02:10,160
پارامتر به این تابع وارد می کنیم،
66
00:02:10,160 –> 00:02:11,760
پارامترهای یک تابع یک
67
00:02:11,760 –> 00:02:14,080
مرجع سخت به مقدار نیز دارند، بنابراین
68
00:02:14,080 –> 00:02:15,760
افزایش می یابد. به
69
00:02:15,760 –> 00:02:16,879
2. البته اگر این را به
70
00:02:16,879 –> 00:02:19,599
چیز دیگری نسبت دهیم، بنابراین اگر d برابر با c باشد، بنابراین
71
00:02:19,599 –> 00:02:21,200
یک مرجع دیگر در اینجا
72
00:02:21,200 –> 00:02:22,560
خواهید دید که ما اکنون
73
00:02:22,560 –> 00:02:24,319
تعداد ارجاعات 3 را داریم و
74
00:02:24,319 –> 00:02:26,720
اگر این کار را چندین بار انجام دهیم، ثابت است. Unassign
75
00:02:26,720 –> 00:02:28,560
d در اینجا تعداد مراجع را به دو کاهش می دهیم
76
00:02:28,560 –> 00:02:30,480
77
00:02:30,480 –> 00:02:32,720
و البته اگر c
78
00:02:32,720 –> 00:02:34,400
uh را حذف کنیم،
79
00:02:34,400 –> 00:02:35,680
می دانیم که تعداد ارجاع ارسال شده
80
00:02:35,680 –> 00:02:37,920
را به صفر فرستاده است و این باعث
81
00:02:37,920 –> 00:02:39,840
می شود شیء زباله جمع شود و
82
00:02:39,840 –> 00:02:42,000
البته این همه c است. مخصوص پایتون،
83
00:02:42,000 –> 00:02:43,440
جمعآورنده زباله در
84
00:02:43,440 –> 00:02:45,760
پی پی و سایر پیادهسازیهای پایتون
85
00:02:45,760 –> 00:02:47,120
86
00:02:47,120 –> 00:02:49,040
بهطور متفاوتی کار میکند، بنابراین اکنون که ما به نوعی ایدهای پایه داریم
87
00:02:49,040 –> 00:02:51,200
که شمارش ارجاعات چیست،
88
00:02:51,200 –> 00:02:55,280
یک مرجع ضعیف به شما امکان میدهد یک
89
00:02:55,280 –> 00:02:57,200
تخصیص برای یک شی ایجاد کنید، اما نه
90
00:02:57,200 –> 00:02:59,599
افزایش کد مرجع را nt کنید، بنابراین ما به
91
00:02:59,599 –> 00:03:01,599
عقب برمی گردیم و همان
92
00:03:01,599 –> 00:03:04,319
مثال خود را در اینجا می سازیم، یک c ایجاد می کنیم
93
00:03:04,319 –> 00:03:07,760
، ماژول wecraft را وارد می کنیم و
94
00:03:07,760 –> 00:03:09,760
یک
95
00:03:09,760 –> 00:03:11,239
تخصیص دیگر را انجام می دهیم، اما در این مورد از
96
00:03:11,239 –> 00:03:14,400
ضعیف Ref از c استفاده می
97
00:03:14,400 –> 00:03:15,560
کنیم و اگر
98
00:03:15,560 –> 00:03:17,120
sys.getrefcount
99
00:03:17,120 –> 00:03:19,760
را انجام دهیم باز هم خواهد بود. 2. حتی اگر در اینجا به
100
00:03:19,760 –> 00:03:21,760
نوعی یک شی c داریم،
101
00:03:21,760 –> 00:03:23,440
می توانید ببینید که یک گراف ضعیف است
102
00:03:23,440 –> 00:03:26,000
که به این شی خاص c اشاره می کند
103
00:03:26,000 –> 00:03:27,680
و نحوه عملکرد شی گراف ضعیف به
104
00:03:27,680 –> 00:03:30,239
طور پیش فرض این است که اگر آن را فراخوانی
105
00:03:30,239 –> 00:03:31,840
کنید، یا دریافت خواهید کرد
106
00:03:31,840 –> 00:03:33,680
اگر شی
107
00:03:33,680 –> 00:03:35,040
جمعآوری شده
108
00:03:35,040 –> 00:03:36,720
باشد، هیچکدام را برمیگردانید، بهعنوان مثال، اگر همین کار را انجام دهیم c
109
00:03:36,720 –> 00:03:39,360
برابر با هیچکدام در اینجا نیست،
110
00:03:39,360 –> 00:03:40,640
حتی میتوانیم آن را به مقدار دیگری اختصاص دهیم،
111
00:03:40,640 –> 00:03:42,239
فقط برای
112
00:03:42,239 –> 00:03:43,840
اینکه بین بازگرداندن هیچکدام و
113
00:03:43,840 –> 00:03:47,280
بازگرداندن آن مقدار تفاوت قائل شویم. c را در اینجا اختصاص دهید
114
00:03:47,280 –> 00:03:48,720
که باید جمعآوری میشد، چرا
115
00:03:48,720 –> 00:03:51,599
جمعآوری نشد، این هنوز هم
116
00:03:51,599 –> 00:03:52,879
117
00:03:52,879 –> 00:03:55,200
شی ما را نشان میدهد، اوم،
118
00:03:55,200 –> 00:03:57,120
چون ما یک عبارت داریم درست
119
00:03:57,120 –> 00:03:58,640
وقتی این عبارت را اینجا صدا
120
00:03:58,640 –> 00:04:00,319
زدم، آن را در زیر خط ذخیره میکند که فوقالعاده است
121
00:04:00,319 –> 00:04:02,080
گیج کننده است اجازه دهید من این نسخه نمایشی را دوباره
122
00:04:02,080 –> 00:04:04,080
انجام دهم، جایی که در واقع آن را به طور تصادفی در زیرخط ذخیره نکنم،
123
00:04:04,080 –> 00:04:06,239
124
00:04:06,239 –> 00:04:08,400
بنابراین c برابر c را انجام می دهیم، d برابر
125
00:04:08,400 –> 00:04:10,720
با نقطه ref از c می
126
00:04:10,720 –> 00:04:12,319
سازیم و
127
00:04:12,319 –> 00:04:15,360
فراخوانی d را چاپ می کنیم به این ترتیب ما
128
00:04:15,360 –> 00:04:16,720
آن را در آن
129
00:04:16,720 –> 00:04:19,040
متغیر زیرخط ذخیره نمی کنیم و اکنون اگر
130
00:04:19,040 –> 00:04:21,680
c را به پنج اختصاص دهیم این باعث می شود که c
131
00:04:21,680 –> 00:04:24,080
زباله جمع شود و اگر
132
00:04:24,080 –> 00:04:26,800
دوباره سعی کنیم و d را فراخوانی کنیم هیچ کدام را برمی
133
00:04:26,800 –> 00:04:28,639
گردانیم و بنابراین این روش فراخوانی است چگونه به
134
00:04:28,639 –> 00:04:29,360
135
00:04:29,360 –> 00:04:32,720
طور صریح به آن شی زیربنایی دسترسی پیدا می کنید
136
00:04:32,720 –> 00:04:34,400
137
00:04:34,400 –> 00:04:36,560
و این می تواند در نوع دو
138
00:04:36,560 –> 00:04:38,479
مورد اصلی که من دیدم مفید باشد، یکی
139
00:04:38,479 –> 00:04:40,320
ایجاد حافظه پنهان است
140
00:04:40,320 –> 00:04:41,840
زیرا کش ها اغلب
141
00:04:41,840 –> 00:04:44,320
متغیرهای سراسری هستند و ساده لوحانه اگر
142
00:04:44,320 –> 00:04:46,639
چیزهایی را در آنها بچسبانید و اوه می دانید که
143
00:04:46,639 –> 00:04:48,000
آنها زباله می شوند. بعدا جمع آوری شده و
144
00:04:48,000 –> 00:04:49,759
دیگر در برنامه به آنها ارجاع داده نمی شود، شما
145
00:04:49,759 –> 00:04:51,280
به طور طبیعی در این
146
00:04:51,280 –> 00:04:53,600
کش جهانی نشت حافظه دارید، اما اگر از یک ref ضعیف استفاده می کنید،
147
00:04:53,600 –> 00:04:55,600
آنها نگه نمی دارند
148
00:04:55,600 –> 00:04:57,600
که آن شی را تشدید
149
00:04:57,600 –> 00:04:58,720
نمی کند، زیرا ندارد. یک مرجع قوی
150
00:04:58,720 –> 00:04:59,680
151
00:04:59,680 –> 00:05:02,000
مورد دیگری که من دیده ام
152
00:05:02,000 –> 00:05:03,840
بهبود t است عملکرد
153
00:05:03,840 –> 00:05:06,639
جمعآوری زباله در مورد ارجاعات دایرهای
15