www.久久久久|狼友网站av天堂|精品国产无码a片|一级av色欲av|91在线播放视频|亚洲无码主播在线|国产精品草久在线|明星AV网站在线|污污内射久久一区|婷婷综合视频网站

當(dāng)前位置:首頁 > 單片機 > 程序喵大人
[導(dǎo)讀]內(nèi)存泄漏是指由于疏忽或錯誤造成程序未能釋放已經(jīng)不再使用的內(nèi)存。內(nèi)存泄漏并非指內(nèi)存在物理上的消失,而是應(yīng)用程序分配某段內(nèi)存后,由于設(shè)計錯誤,導(dǎo)致在釋放該段內(nèi)存之前就失去了對該段內(nèi)存的控制,從而造成了內(nèi)存的浪費。 我們平時開發(fā)過程中不可避免的會

內(nèi)存泄漏是指由于疏忽或錯誤造成程序未能釋放已經(jīng)不再使用的內(nèi)存。內(nèi)存泄漏并非指內(nèi)存在物理上的消失,而是應(yīng)用程序分配某段內(nèi)存后,由于設(shè)計錯誤,導(dǎo)致在釋放該段內(nèi)存之前就失去了對該段內(nèi)存的控制,從而造成了內(nèi)存的浪費。

我們平時開發(fā)過程中不可避免的會遇到內(nèi)存泄漏問題,你是如何排查的呢?估計你是使用下面這幾個工具吧?

  • valgrind

  • mtrace

  • dmalloc

  • ccmalloc

  • memwatch

  • debug_new

這里程序喵向大家推薦新的一個排查內(nèi)存泄漏的工具:AddressSanitizer(ASan),該工具為gcc自帶,4.8以上版本都可以使用,支持Linux、OS、Android等多種平臺,不止可以檢測內(nèi)存泄漏,它其實是一個內(nèi)存錯誤檢測工具,可以檢測的問題有:

  • 內(nèi)存泄漏

  • 堆棧和全局內(nèi)存越界訪問

  • free后繼續(xù)使用

  • 局部內(nèi)存被外層使用

  • Initialization order bugs(中文不知道怎么翻譯才好,后面有代碼舉例,重要)

使用方法直接看我下面的代碼:

檢測內(nèi)存泄漏

內(nèi)存泄漏代碼:

#include <stdlib.h>
void func1() { malloc(7); }
void func2() { malloc(5); }
int main() { func1(); func2(); return 0;}

編譯and輸出

g++ -fsanitize=address -g test_leak.cc && ./a.out
===================================================================103==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 7 byte(s) in 1 object(s) allocated from: #0 0x7f95b231eb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f95b36007f7 in func1() /home/wangzhiqiang/test/test_leak.cc:3 #2 0x7f95b3600814 in main /home/wangzhiqiang/test/test_leak.cc:8 #3 0x7f95b1e61b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
Direct leak of 5 byte(s) in 1 object(s) allocated from: #0 0x7f95b231eb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40) #1 0x7f95b3600808 in func2() /home/wangzhiqiang/test/test_leak.cc:5 #2 0x7f95b3600819 in main /home/wangzhiqiang/test/test_leak.cc:9 #3 0x7f95b1e61b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
SUMMARY: AddressSanitizer: 12 byte(s) leaked in 2 allocation(s).

編譯方式很簡單,只需要添加-fsanitize=address -g就可以檢測出具體產(chǎn)生內(nèi)存泄漏的位置以及泄漏空間的大小。

檢測堆棧內(nèi)存越界訪問

示例:

#include <iostream>
int main() { int *array = new int[100]; array[0] = 0; int res = array[100]; // out of bounds delete[] array; return res;}

編譯and輸出:

g++ -fsanitize=address -g test_leak.cc && ./a.out ===================================================================110==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6140000001d0 at pc 0x7f0e06400d2e bp 0x7ffff5963f10 sp 0x7ffff5963f00READ of size 4 at 0x6140000001d0 thread T0 #0 0x7f0e06400d2d in main /home/wangzhiqiang/test/test_leak.cc:6 #1 0x7f0e048d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #2 0x7f0e06400bb9 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xbb9)
0x6140000001d0 is located 0 bytes to the right of 400-byte region [0x614000000040,0x6140000001d0)allocated by thread T0 here: #0 0x7f0e05120608 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608) #1 0x7f0e06400cab in main /home/wangzhiqiang/test/test_leak.cc:4 #2 0x7f0e048d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/wangzhiqiang/test/test_leak.cc:6 in mainShadow bytes around the buggy address: 0x0c287fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff8000: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c287fff8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x0c287fff8030: 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa 0x0c287fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8060: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8070: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa faShadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb==110==ABORTING

可以方便定位到堆棧內(nèi)存越界訪問的錯誤。

全局內(nèi)存越界訪問

示例:

#include <iostream>
int global_array[100] = {0};
int main() { int res = global_array[100]; // out of bounds return 0;}

編譯and輸出:

g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================116==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f42e6e02310 at pc 0x7f42e6c00c84 bp 0x7fffdda52780 sp 0x7fffdda52770READ of size 4 at 0x7f42e6e02310 thread T0 #0 0x7f42e6c00c83 in main /home/wangzhiqiang/test/test_leak.cc:6 #1 0x7f42e50d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #2 0x7f42e6c00b69 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb69)
0x7f42e6e02310 is located 0 bytes to the right of global variable 'global_array' defined in 'test_leak.cc:3:5' (0x7f42e6e02180) of size 400SUMMARY: AddressSanitizer: global-buffer-overflow /home/wangzhiqiang/test/test_leak.cc:6 in mainShadow bytes around the buggy address: 0x0fe8dcdb8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8420: 00 00 00 00 00 00 00 00 01 f9 f9 f9 f9 f9 f9 f9 0x0fe8dcdb8430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x0fe8dcdb8460: 00 00[f9]f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x0fe8dcdb8470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb8490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb84a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe8dcdb84b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb==116==ABORTING

局部內(nèi)存被外層使用

示例:

#include <iostream>
volatile int *p = 0;
int main() {{ int x = 0; p = &x;} *p = 5; return 0;}

編譯and輸出:

g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================243==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fffce12a4b0 at pc 0x7f3993e00e7e bp 0x7fffce12a480 sp 0x7fffce12a470WRITE of size 4 at 0x7fffce12a4b0 thread T0 #0 0x7f3993e00e7d in main /home/wangzhiqiang/test/test_leak.cc:10 #1 0x7f39922d1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #2 0x7f3993e00c89 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xc89)
Address 0x7fffce12a4b0 is located in stack of thread T0 at offset 32 in frame #0 0x7f3993e00d79 in main /home/wangzhiqiang/test/test_leak.cc:5
This frame has 1 object(s): [32, 36) 'x' <== Memory access at offset 32 is inside this variableHINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported)SUMMARY: AddressSanitizer: stack-use-after-scope /home/wangzhiqiang/test/test_leak.cc:10 in mainShadow bytes around the buggy address:0x100079c1d440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x100079c1d490: 00 00 f1 f1 f1 f1[f8]f2 f2 f2 00 00 00 00 00 000x100079c1d4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000x100079c1d4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow byte legend (one shadow byte represents 8 application bytes):Addressable: 00Partially addressable: 01 02 03 04 05 06 07Heap left redzone: faFreed heap region: fdStack left redzone: f1Stack mid redzone: f2Stack right redzone: f3Stack after return: f5Stack use after scope: f8Global redzone: f9Global init order: f6Poisoned by user: f7Container overflow: fcArray cookie: acIntra object redzone: bbASan internal: feLeft alloca redzone: caRight alloca redzone: cb==243==ABORTING

free后被使用

示例:

#include <iostream>
int main() { int *array = new int[100]; delete[] array; int a = array[0]; // error return 0;}

編譯and輸出:

g++ -fsanitize=address -g test_leak.cc && ./a.out===================================================================282==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000000040 at pc 0x7f209fa00caa bp 0x7ffff2a15020 sp 0x7ffff2a15010READ of size 4 at 0x614000000040 thread T0 #0 0x7f209fa00ca9 in main /home/wangzhiqiang/test/test_leak.cc:6 #1 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #2 0x7f209fa00b69 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb69)
0x614000000040 is located 0 bytes inside of 400-byte region [0x614000000040,0x6140000001d0)freed by thread T0 here: #0 0x7f209e721480 in operator delete[](void*) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe1480) #1 0x7f209fa00c72 in main /home/wangzhiqiang/test/test_leak.cc:5 #2 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
previously allocated by thread T0 here: #0 0x7f209e720608 in operator new[](unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0608) #1 0x7f209fa00c5b in main /home/wangzhiqiang/test/test_leak.cc:4 #2 0x7f209ded1b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
SUMMARY: AddressSanitizer: heap-use-after-free /home/wangzhiqiang/test/test_leak.cc:6 in mainShadow bytes around the buggy address: 0x0c287fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c287fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00=>0x0c287fff8000: fa fa fa fa fa fa fa fa[fd]fd fd fd fd fd fd fd 0x0c287fff8010: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c287fff8020: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c287fff8030: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa 0x0c287fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c287fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa faShadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb==282==ABORTING

Initialization order bugs

示例,這里有兩個文件:

// test_memory1.cc#include <stdio.h>
extern int extern_global;int read_extern_global() { return extern_global; }
int x = read_extern_global() + 1;
int main() { printf("%d\n", x); return 0;}
// test_memory2.cc
int foo() { return 123; }int extern_global = foo();

第一種編譯方式輸出如下:

g++ test_memory1.cc test_memory2.cc && ./a.out1

第二種編譯方式輸出如下:

g++ test_memory2.cc test_memory1.cc && ./a.out124

這種問題我們平時編程過程中可以都不會太注意,然而通過ASan可以檢測出這種潛在的bug:

編譯and輸出:

g++ -fsanitize=address -g test_memory1.cc test_memory2.cc
ASAN_OPTIONS=check_initialization_order=true:strict_init_order=true ./a.out===================================================================419==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x7f46c20021a0 at pc 0x7f46c1e00c28 bp 0x7fffe423d920 sp 0x7fffe423d910READ of size 4 at 0x7f46c20021a0 thread T0 #0 0x7f46c1e00c27 in read_extern_global() /home/wangzhiqiang/test/test_memory1.cc:3 #1 0x7f46c1e00cb3 in __static_initialization_and_destruction_0 /home/wangzhiqiang/test/test_memory1.cc:4 #2 0x7f46c1e00d0a in _GLOBAL__sub_I__Z18read_extern_globalv /home/wangzhiqiang/test/test_memory1.cc:8 #3 0x7f46c1e00e5c in __libc_csu_init (/mnt/d/wzq/wzq/util/test/a.out+0xe5c) #4 0x7f46c0461b27 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b27) #5 0x7f46c1e00b09 in _start (/mnt/d/wzq/wzq/util/test/a.out+0xb09)
0x7f46c20021a0 is located 0 bytes inside of global variable 'extern_global' defined in 'test_memory2.cc:2:5' (0x7f46c20021a0) of size 4 registered at: #0 0x7f46c08764a8 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x364a8) #1 0x7f46c1e00e0b in _GLOBAL__sub_I_00099_1__Z3foov (/mnt/d/wzq/wzq/util/test/a.out+0xe0b) #2 0x7f46c1e00e5c in __libc_csu_init (/mnt/d/wzq/wzq/util/test/a.out+0xe5c)
SUMMARY: AddressSanitizer: initialization-order-fiasco /home/wangzhiqiang/test/test_memory1.cc:3 in read_extern_global()Shadow bytes around the buggy address: 0x0fe9583f83e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe9583f83f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe9583f8400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe9583f8410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe9583f8420: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9=>0x0fe9583f8430: 00 00 00 00[f6]f6 f6 f6 f6 f6 f6 f6 00 00 00 00 0x0fe9583f8440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe9583f8450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe9583f8460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe9583f8470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0fe9583f8480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb==419==ABORTING

注意:這里在運行程序前需要添加環(huán)境變量:

ASAN_OPTIONS=check_initialization_order=true:strict_init_order=true

小總結(jié)

ASan是個很好的檢測內(nèi)存問題的工具,不需要配置環(huán)境,使用還方便,編譯時只需要-fsanitize=address -g就可以,運行程序時候可以選擇添加對應(yīng)的ASAN_OPTIONS環(huán)境變量就可以檢測出很多內(nèi)存問題。它的錯誤信息也很有用,明確指出當(dāng)前是什么類型的內(nèi)存錯誤,如:

  • detected memory leaks

  • heap-buffer-overflow

  • stack-buffer-overflow

  • global-buffer-overflow

  • heap-use-after-free

  • initialization-order-fiasco

具體可以看google的官方文檔:https://github.com/google/sanitizers/wiki/AddressSanitizer



c++11新特性,所有知識點都在這了!

你的c++團隊還在禁用異常處理嗎?

內(nèi)存對齊之格式修訂版

c++11新特性之智能指針



免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關(guān)機構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

LED驅(qū)動電源的輸入包括高壓工頻交流(即市電)、低壓直流、高壓直流、低壓高頻交流(如電子變壓器的輸出)等。

關(guān)鍵字: 驅(qū)動電源

在工業(yè)自動化蓬勃發(fā)展的當(dāng)下,工業(yè)電機作為核心動力設(shè)備,其驅(qū)動電源的性能直接關(guān)系到整個系統(tǒng)的穩(wěn)定性和可靠性。其中,反電動勢抑制與過流保護是驅(qū)動電源設(shè)計中至關(guān)重要的兩個環(huán)節(jié),集成化方案的設(shè)計成為提升電機驅(qū)動性能的關(guān)鍵。

關(guān)鍵字: 工業(yè)電機 驅(qū)動電源

LED 驅(qū)動電源作為 LED 照明系統(tǒng)的 “心臟”,其穩(wěn)定性直接決定了整個照明設(shè)備的使用壽命。然而,在實際應(yīng)用中,LED 驅(qū)動電源易損壞的問題卻十分常見,不僅增加了維護成本,還影響了用戶體驗。要解決這一問題,需從設(shè)計、生...

關(guān)鍵字: 驅(qū)動電源 照明系統(tǒng) 散熱

根據(jù)LED驅(qū)動電源的公式,電感內(nèi)電流波動大小和電感值成反比,輸出紋波和輸出電容值成反比。所以加大電感值和輸出電容值可以減小紋波。

關(guān)鍵字: LED 設(shè)計 驅(qū)動電源

電動汽車(EV)作為新能源汽車的重要代表,正逐漸成為全球汽車產(chǎn)業(yè)的重要發(fā)展方向。電動汽車的核心技術(shù)之一是電機驅(qū)動控制系統(tǒng),而絕緣柵雙極型晶體管(IGBT)作為電機驅(qū)動系統(tǒng)中的關(guān)鍵元件,其性能直接影響到電動汽車的動力性能和...

關(guān)鍵字: 電動汽車 新能源 驅(qū)動電源

在現(xiàn)代城市建設(shè)中,街道及停車場照明作為基礎(chǔ)設(shè)施的重要組成部分,其質(zhì)量和效率直接關(guān)系到城市的公共安全、居民生活質(zhì)量和能源利用效率。隨著科技的進步,高亮度白光發(fā)光二極管(LED)因其獨特的優(yōu)勢逐漸取代傳統(tǒng)光源,成為大功率區(qū)域...

關(guān)鍵字: 發(fā)光二極管 驅(qū)動電源 LED

LED通用照明設(shè)計工程師會遇到許多挑戰(zhàn),如功率密度、功率因數(shù)校正(PFC)、空間受限和可靠性等。

關(guān)鍵字: LED 驅(qū)動電源 功率因數(shù)校正

在LED照明技術(shù)日益普及的今天,LED驅(qū)動電源的電磁干擾(EMI)問題成為了一個不可忽視的挑戰(zhàn)。電磁干擾不僅會影響LED燈具的正常工作,還可能對周圍電子設(shè)備造成不利影響,甚至引發(fā)系統(tǒng)故障。因此,采取有效的硬件措施來解決L...

關(guān)鍵字: LED照明技術(shù) 電磁干擾 驅(qū)動電源

開關(guān)電源具有效率高的特性,而且開關(guān)電源的變壓器體積比串聯(lián)穩(wěn)壓型電源的要小得多,電源電路比較整潔,整機重量也有所下降,所以,現(xiàn)在的LED驅(qū)動電源

關(guān)鍵字: LED 驅(qū)動電源 開關(guān)電源

LED驅(qū)動電源是把電源供應(yīng)轉(zhuǎn)換為特定的電壓電流以驅(qū)動LED發(fā)光的電壓轉(zhuǎn)換器,通常情況下:LED驅(qū)動電源的輸入包括高壓工頻交流(即市電)、低壓直流、高壓直流、低壓高頻交流(如電子變壓器的輸出)等。

關(guān)鍵字: LED 隧道燈 驅(qū)動電源
關(guān)閉