深入探究 C++ 编程中的资源泄漏问题

目录

1、GDI对象泄漏

1.1、何为GDI资源泄漏？

1.2、使用GDIView工具排查GDI对象泄漏

1.3、有时可能需要结合其他方法去排查

1.4、如何保证没有GDI对象泄漏？

2、进程句柄泄漏

2.1、何为进程句柄泄漏？

2.2、创建线程时的线程句柄泄漏 

3、内存泄漏

3.1、在多态中没有将父类的析构函数声明为virtual函数，导致没有执行到子类的析构函数

3.2、使用智能指针shared_ptr发生循环引用问题，导致内存泄漏

3.3、第三方注入库有内存泄漏，导致进程有内存泄漏

3.4、内存泄漏的危害

3.5、内存泄漏的排查

4、最后

VC++常用功能开发汇总（专栏文章列表，欢迎订阅，持续更新...）icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/124272585C++软件异常排查从入门到精通系列教程（专栏文章列表，欢迎订阅，持续更新...）icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/125529931C++软件分析工具从入门到精通案例集锦（专栏文章正在更新中...）icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/131405795C/C++基础与进阶（专栏文章，持续更新中...）icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/category_11931267.html       在C++程序开发维护过程中，时常会遇到资源泄漏问题，比如GDI对象泄漏、进程线程句柄泄漏以及内存泄漏问题。今天我们就来深入探讨一下这几类资源泄漏以及排查这些泄露的办法。

1、GDI对象泄漏

        在Windows平台上，做UI客户端编程，很多时候都是使用系统GDI对象进行窗口的绘制，常见的GDI对象有Pen（用来绘制线条的画笔）、Brush（用来填充颜色的画刷）、Bitmap（用来处理图片的位图）、Font（用来设置文字大小的字体）、Region（区域）、DC（设备上下文）等。

1.1、何为GDI资源泄漏？

       对于Pen、Brush、Bitmap和Region等，在使用前我们需要调用创建这些对象的接口把对象创建出来，比如CreatePen/CreatePenIndirect、CreateSolidBrush/CreateBrushIndirect、CreateFont/CreateFontIndirect、CreateCompatibleBitmap等API接口，然后在使用完这些对象后需要调用DeleteObject将对象释放掉。对于DC对象，则一般调用GetDC去获取窗口的DC对象，然后在不使用时需要调用ReleaseDC将DC释放掉。如果不释放这些对象，则会导致GDI对象泄漏。

在Windows程序中，一个进程的GDI对象总数是有上限的，默认情况下上限值为10000个。可以从如下的注册表中可以看到，这个值是系统设置的默认值，一般情况下不用修改，即使修改，也不能改成很大的值。

       如果发生GDI对象泄漏的代码段，频繁地执行，程序在持续运行一段时间后，进程的GDI对象总数接近或达到10000个上限。当接近上限时，就会出现GDI绘图函数内部发生错误，返回失败，导致窗口绘制异常。紧接着可能就会产生崩溃闪退。

1.2、使用GDIView工具排查GDI对象泄漏

       GDI对象持续泄漏，对程序可能是致命的，一旦接近或达到上限，就会导致程序发声崩溃闪退。GDI对象泄漏问题，排查起来相对容易一些，先用GDIView工具先看一下是哪类GDI对象有泄漏：

然后有针对性的查看操作这类GDI对象的代码，然后逐步缩小排查的范围。

       如果出现窗口绘制或显示异常，或者程序无故闪退，可以到任务管理器中查看进程的GDI对象总数的值：（默认情况下不显示GDI对象列，右键点击标题栏，在弹出窗口中勾选GDI对象选项即可显示）

如果总数接近10000个，肯定是GDI对象泄漏导致的。可以重新启动程序，然后再任务管理器中持续观察进程的GDI对象总数。

1.3、有时可能需要结合其他方法去排查

       有时也要结合其他方法来辅助定位，比如可以使用历史版本比对法，看看是从哪天开始出现泄漏。然后查看前一天svn或git上的代码提交记录，或者底层模块库发布记录，这样就能有效的缩小问题的排查范围。有次项目中出的问题，就出在底层的WebRTC开源库中。当时排查了UI层的代码没有找到泄漏点，所以怀疑可能是底层模块有问题。

       当时找到了问题的复现办法，然后使用历史版本比对法，确定了从哪一天开始出现泄漏。然后查看了svn上的代码提交记录以及底层库的发布记录， 发现出问题前一天底层开源组件组发布了新版本的WebRTC开源库，在这个版本中开源组件组为了处理一个bug，添加了一段代码，于是找开源组件的同事排查一下他们提交的代码，看看是否存在GDI泄漏。一小段时间后，他们给出结论，说他们新加的代码没问题，应该是其他模块引发的。但根据历史版本比对法的对比，问题应该就出在WebRTC开源库中，但开源组件组始终觉得他们的代码没问题。

       于是我到开源组件组那边查看svn上他们的代码修改记录，看到他们新增的一段代码果然有问题，如下所示：

#if defined (WEBRTC_WIN)//修正程序开启DWM导致的鼠标位置问题int desktop_horzers = GetDeviceCaps( GetDC(nullptr) DESKTOPHORZRES); // 问题就出在这个GetDC上int horzers = GetDeviceCaps(GetDC(nullptr),HORZRES);float scale_rate=(float)desktop_horzers/(float)horzers;relative_position.set( relative_ position.x()*scale_rate, relative_ position.y()*scale_rate );
#endif

这段代码中，他们调用GetDC接口获取窗口的DC对象，在使用完DC对象后，没有调用ReleaseDC将DC对象释放掉，所以导致了DC对象的泄漏。修改后的代码如下：

#if defined (WEBRTC_WIN)//修正程序开启DWM导致的鼠标位置问题HDC hDC = ::GetDC(nullptr);int desktop_horzers = GetDeviceCaps( hDC, DESKTOPHORZRES);int horzers = GetDeviceCaps(hDC,HORZRES);float scale_rate=(float)desktop_horzers/(float)horzers;relative_position.set( relative_ position.x()*scale_rate, relative_ position.y()*scale_rate );::ReleaseDC(nullptr, hDC);
#endif

至于开源组件的同事没找到问题，可能是他们对UI编程不熟悉导致的。

      另一个GDI对象泄漏排查实例，可以参见我之前写的文章：

使用GDIView工具排查GDI对象泄漏导致程序UI界面绘制异常的问题https://blog.csdn.net/chenlycly/article/details/128625868icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/128625868

1.4、如何保证没有GDI对象泄漏？

       要保证不出现GDI对象泄漏，在GDI对象使用完成后要将之删除或释放掉，如果不删除或释放，则会导致GDI泄漏。比如使用CreateXXXXXX创建的GDI对象，使用完后，要用DeleteObject释放；调用LoadXXXXXX函数去加载图片资源，使用完后，也要用DeleteObject释放；调用CreateXXXDC创建的DC对象，使用完后，要用DeleteDC去释放；调用GetDC获取到的DC对象，使用完后，要用ReleaseDC释放。

       调用不用的接口去创建或获取GDI对象，释放时也要调用对应的释放接口，不能混淆！在这里给大家大概的罗列一下：

创建或获取GDI对象删除或释放GDI对象
CreatePen/CreatePenIndirect（pen画笔对象）、CreateSolidBrush/CreateBrushIndirect（brush画刷对象）、CreateFont/CreateFontIndirect（Font字体对象）、CreateCompatibleBitmap（BItmap位图对象）对于Create出来的对象，要调用DeleteObject释放
CreateDC/CreateCompatibleDC（创建DC对象）调用DeleteDC释放
GetDC（获取DC对象）调用ReleaseDC释放
LoadBitmap（加载Bitmap位图）调用DeleteObject释放
LoadImage（加载图片资源）

如果加载的是Bitmap位图，则调用DeleteObject释放；

如果加载的是Cursor光标，则调用DestroyCursor释放；

如果加载的是Icon图标，则调用DestroyIcon释放。

对于上面提到的创建GDI对象的API函数，在释放时该调用哪个接口，直接到MSDN上查看API接口的Remarks部分就会找到对应的说明。比如创建兼容位图的API函数CreateCompatibleBItmap，在Remaks部分的说明如下：

 再比如加载图片的API函数LoadImage，其在Remarks部分的说明如下：

在调用Windows系统API函数遇到问题时，需要到微软MSDN帮助页面中查看API函数的详细说明（可能会给出调用函数时的注意事项，或者调用函数的示例代码等），在说明中可能会找到相关的原因！会使用MSDN，是一个Windows开发人员最基本的要求！

2、进程句柄泄漏

       进程句柄包括文件句柄（打开文件时产生的句柄）、注册表句柄（打开注册表节点时产生的句柄）、事件句柄、信号量句柄、线程句柄（创建线程时产生的句柄）、进程句柄（创建子进程时产生的句柄）等。

2.1、何为进程句柄泄漏？

       这些句柄在使用完成后需要及时释放，如果不释放，则会造成句柄泄漏。一般调用CloseHandle去释放句柄，比如进程句柄、线程句柄、事件句柄、文件句柄等。当然也有部分句柄需要对应的接口去释放，比如注册表句柄需要调用RegCloseKey去关闭。

       在Winows系统中，进程句柄数也是有上限的，默认也是10000个，也有对应的注册表项。当进程的句柄数接近或达到10000个上限时，就会导致后续产生句柄的操作会执行失败，比如调用CreateThread去创建新的线程会失败。关于进程GDI对象上限值的注册表设置路径为：

计算机\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

不仅进程的GDI对象有上限，进程的句柄数（比如线程句柄、事件句柄等句柄）也是有上限的，默认也是10000个。注册表对应的节点配置如下：

这两个配置项的说明如下：

1）GDIProcessHandleQuota项：设置GDI句柄数量，默认值为2710(16进制)/10000(10进制)，该值的允许范围为 256 ~ 16384 ，将其调整为大于默认的10000的值。如果您的系统配置了2G或更多内容，不妨将其设置为允许的最大值 16384(10进制)。

2）USERProcessHandleQuota项：设置用户句柄数量，默认值同样为2710(16进制)/10000(10进制)，该值的允许范围为 200 ~ 18000 ，将其调整为更多的数值。同样地，对于具有2GB或更多物理内存的系统，不妨将用户句柄数直接设置为上限 18000(10进制)。

2.2、创建线程时的线程句柄泄漏 

       以前我们在项目中就遇到这样的问题，有的业务子系统是通过https和平台服务器交互的，客户端每执行一个https操作时都会创建一个线程去执行，但创建线程后没有调用CloseHanlde将线程句柄关闭掉，导致线程句柄发生泄漏，当多次执行https操作导致线程句柄过多，导致后续再去创建线程创建失败了。可以到Process Explorer中查看进程都占用哪些具体的句柄：

这个地方需要注意一下，调用CloaseHandle将线程句柄释放掉：

HANDLE hThread = ::CreateThread( NULL, NULL, ProcessProc, this, NULL, NULL );
if ( hThread != NULL )
{CloseHandle( hThread );
}

调用CloseHandle将句柄释放掉，并不表示将线程结束掉，线程是否结束是要看线程函数的，线程函数退出了，则线程就结束了。

        线程结束了，不会自动关闭线程句柄。对于线程函数，还有一个细节，发起线程创建的CreateThread函数返回了，不代表线程的代码已经执行到线程函数中了。这点我们在项目中遇到过这类的场景。当时的问题场景是，线程函数中访问了一个指针变量，将该指针变量的值初始化为NULL的操作放在CreateThread函数调用之后，如下所示：

// 1、指针变量定义
CVideoDec* g_pVideoDec；// 2、创建线程
HANDLE hThread = ::CreateThread( NULL, NULL, ProcessProc, this, NULL, NULL );
if ( hThread != NULL )
{CloseHandle( hThread );
}
g_pVideoDec = NULL； // 对指针变量进行初始化// 3、线程函数，函数中访问了指针变量g_pVideoDec
DWORD WINAPI ProcessCachedMsgThreadProc( LPVOID lpParameter )
{// 线程函数中访问到了该指针变量g_pVideoDec->StartDec();return 1;
}

当然这种做法是不规范的，后来发现程序会时不时崩溃在线程函数中，使用Windbg分析下来得知是线程中访问了未初始化的变量，但这个问题不是必现的。这个不必现，就和CreateThread函数返回后线程是否执行到线程函数中有关。

       有时，CreateThread返回时还没执行到线程函数中，紧接着就去初始化指针变量的值，是不会崩溃的。但如果CreateThread返回时已经执行到线程函数中，就会访问未初始化的指针变量，Release下未初始化的内存是个随机值，即指针变量的值为随机值，所以一般都会引发异常。

3、内存泄漏

       内存泄漏是C++程序使用动态申请的内存时容易出现的一类典型内存问题。动态申请内存的方式有多种，比如使用new（要用delete去释放），比如使用malloc（要用free去释放），再比如调用系统API函数HeapCreate或者HeapAlloc（要用HeapFree去释放），还有可以调用API函数VirtualAlloc（要用VirtualFree去释放），当然还有其他的API函数。动态申请的内存没有释放，则会导致内存泄漏。

       之所以会导致内存泄漏，可能是忘记释放，也可能是写了释放内存的代码，但因为种种原因没有执行到内存释放的代码，后面这类情况有一定的隐蔽性。下面我们重点说一下后面的这类情况。       

3.1、在多态中没有将父类的析构函数声明为virtual函数，导致没有执行到子类的析构函数

       比如如下的多态代码：

class CBase
{
public:CBase();~CBase();  // 没有将父类的析构函数设置为虚函数     
} class CDerived : public class CBase
{
public:CDerived();~CDerived();       
} // 将new出来的子类对象赋值给父类指针，就是多态
CBase* pBase = new CDerived;
// ...  // 中间代码省略
delete pBase；

上述代码，因为没有将父类的析构函数~CBase设置为虚函数，导致执行到delete pBase；时没有调用子类的析构函数，导致子类的部分内存没有释放，从而引发内存泄漏。特别是新人比较容易犯这类错误，之前在帮新人排查问题时遇到过，这个场景下的内存泄漏具有一定的隐蔽性。

如果不是析构函数，是其他的成员函数，如果父类的接口没有声明为virtual，多态就不会生效，会导致子类重写的成员函数不会被执行到，子类重写的成员函数中可能包含了重要的业务代码，这样就会导致重要的业务代码没有执行到，导致业务出现异常。

之前我们这边的新人将代码移植到国产化机器上时就遇到过，新人忘记在父类的接口前添加virtual声明，导致子类的接扣执行不到，导致业务出现异常，当时他查了很久没找出问题，后来找我去排查，找到这个原因，所以对这个问题印象很深！

       所以，我们在定义C++类时，如果该类可能会被继承，一般都要将父类的析构函数设置为虚函数，防止出现上述多态场景下子类的析构函数执行不到导致内存泄漏的问题。当然，设置虚函数有一定的副作用，如果一个类中包含虚函数，则类中会自动添加一个虚函数表指针，此外虚函数调用时也涉及到二次寻址问题（效率上略有影响）。

3.2、使用智能指针shared_ptr发生循环引用问题，导致内存泄漏

       使用shared_ptr可能会出现循环引用问题，这使用shared_ptr智能指针的一个典型问题（也是一个关于shared_ptr智能指针的面试题），场景是两个类中都包含了指向对方的shared_ptr对象，这样会导致new出来的两个类没有走析构，引发内存泄漏问题。

       循环引用问题的示意图如下：

相关代码如下：

#include <iostream>
#include<memory>using namespace std;class B;
class A{public:shared_ptr<B> bptr;~A(){cout<<"~A()"<<endl;}
}class B
{public:shared_ptr<A> aptr;~B( ){cout<<"~B()"<<endl;}
}int main() {shared_ptr<A> pa(new A()); // 引用加1shared_ptr<B> pb(new B()); // 引用加1pa->bptr = pb; // 引用加1pa->aptr = pa; // 引用加1return 0;
}

执行到上述return 0这句代码时，指向A和B两个对象的引用计数都是2。当退出main函数时，先析构shared_ptr<B> pb对象，B对象的引用计数减1，B对象的引用计数还为1，所以不会delete B对象，不会进入B对象析构函数，所以B类中的shared_ptr<A> aptr成员不会析构，所以此时A对象的引用计数还是2。当析构shared_ptr<A> pa时，A的引用计数减1，A对象的引用计数变为1，所以不会析构A对象。所以上述代码会导致A和B两个new出的对象都没释放，导致内存泄漏。

       为了解决上述问题，引入了weak_ptr，可以将类中包含的shared_ptr成员换成weak_ptr，如下：

相关代码如下：

#include <iostream>
#include<nemory>using namespace std;class B;
class A{public:weak_ptr<B> bptr;  // 使用weak_ptr替代shared_ptr~A(){cout<<"~A()"<<endl;}
}class B
{public:weak_ptr<A> aptr; // 使用weak_ptr替代shared_ptr~B( ){cout<<"~B()"<<endl;}
}int main() {shared_ptr<A> pa(new A());shared_ptr<B> pb(new B());pa->bptr = pb;pa->aptr = pa;return 0;
}

3.3、第三方注入库有内存泄漏，导致进程有内存泄漏

       第三库注入到我们程序进程中有两个典型的场景，一种是输入法模块的注入，一种是第三方安全软件的注入。输入法要支持所有进程的文字输入，正式通过远程注入到所有进程的模块去感知用户的输入的。第三方安全软件，为了监控软件的数据操作，一般也是需要远程注入到进程中的。

       之前项目中就遇到过第三方安全软件的注入模块有内存泄漏，导致进程内存耗尽，引发程序闪退。对于这类问题，可能其他软件运行不会触发内存泄漏，只有我们的软件才会触发内存泄漏，这个需要拿出足够的证据证明是第三方安全软件的注入模块引起的内存泄漏，否则客户会认为这是我们软件的问题，因为其他软件都没问题，客户可能会不承认这与第三方安全软件有关。当时的问题原因是，第三方安全软件处理UDP数据监控的代码有内存泄漏，因为我们的软件有大量的音视频数据收发，走的是UDP，所以触发了第三方安全软件注入模块的内存泄漏。在给出足够的证据后，客户找到第三方安全软件提供商，然后安全厂商才修复了这个bug。

3.4、内存泄漏的危害

        如果发生内存泄漏的代码，不会频繁地的执行，只是偶尔的执行一下，不会引起太大的问题。但如果有内存泄漏的代码，被频繁地执行，则会频繁地泄漏（内存不释放），最终可能会导致进程的内存耗尽，引发Out of memory（内存耗尽）的崩溃。

       进程启动时，系统会给进程分配指定大小的虚拟内存。以32位程序为例，系统会分配4GB的虚拟内存，其中用户态虚拟内存2GB，内核态虚拟内存2GB，一般内存泄漏的代码都在用户态，所以内存持续泄漏会导致用户态虚拟内存被用尽，引发Out of memory的崩溃。当然，对于64位程序，会分配足够大的虚拟内存。但用户的电脑可能很多天不关机，软件一直在持续的运行，如果有持续的内存泄漏，总有内存用尽的那一天。

       我们可以通过Windows自带的任务管理器：

去持续观察目标进程的内存变化情况，如果内存持续增长不回落，则可能存在内存泄漏。

       此外，Windows自带的任务管理器看不到进程的总的虚拟内存占用，可以使用Process Explorer工具查看进程占用的总虚拟内存，该工具显示的是用户态的虚拟内存占用：

我们一般只需要关注用户态的虚拟内存，因为业务代码占用的是用户态的虚拟内存。 

我们的程序是32位的，系统给进程分配了4GB的虚拟内存，其中用户态虚拟内存占2GB，内核态虚拟内存占2GB，从上图中看，当前程序进程的用户态虚拟内存占用达到1.7GB，已经快接近2GB的上限了，可能再运行一会，2GB用户态的内存就要耗尽了，程序就会闪退！

       注意，Process Explorer工具默认是不显示Virtual Size虚拟内存列，需要右键点击进程列表的标题栏，点击“Select Columns”，在弹出的窗口中点击“Process Memory”标签页，然后将“Virtual Size”选项：

3.5、内存泄漏的排查

       内存泄漏问题的排查，相对比较麻烦，但可以使用一些工具去分析。

3.5.1、Windows平台上内存泄漏的排查

       在Windows平台上，可以使用Windbg（使用!heap命令）、umdh.exe（该工具位于Windbg的安装目录中）、DebugDiag、VMMAP以及Visual C++专用的Visual Leak Detector等工具。对于Visual Leak Detector工具，需要将相关的库编译到模块中。其他几个工具，则可以直接使用。

       关于如何使用umdh.exe工具去检测内存泄漏问题，可以参见我之前写的文章：

使用Windbg定位Windows C++程序中的内存泄漏https://blog.csdn.net/chenlycly/article/details/121295720icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/121295720       关于如何使用Visual Leak Detector工具去排查，可以参见我之前写的文章：
使用Visual Leak Detector排查内存泄漏问题icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/133041372      内存泄漏问题的定位，也不太容易，上述工具可能只能检测某些场景下的内存泄漏，如果在使用一个工具检测不出来时，可以使用其他工具试试。

       此外，从Visual Studio 2019的16.9版本开始，Visual Studio引入了google的强大内存监测工具AddressSanitizer（AddressSanitizer原先只在Linux系统中被支持，继承在gcc中），就像gcc那样提供编译选项上的支持：

在安装高版本的Visual Studio时，可以将“C++ AddressSanitizer”安装选项勾选上，这样Visual Studio中就支持AddressSanitizer了。

AddressSanitizer（简称ASan）是google提供的一款面向C/C++语言的内存错误问题检查工具，它可以检测出堆溢出（Heap buffer overflow）、栈溢出（Stack buffer overflow）、全局变量越界（Global buffer overflow）、已释放内存使用（Use after free ）、初始化顺序（Initialization order bugs）、内存泄漏（Use after free ）等多个内存问题。

AddressSanitizer项目地址：https://github.com/google/sanitizers/wiki/AddressSanitizer

参考文档页面：AddressSanitizerAlgorithm · google/sanitizers Wiki · GitHub

       如果要使用AddressSanitizer内存检测工具，必须要使用Visual Studio 2019的16.9及以上的版本。此外，AddressSanitizer不能像Windbg那样独立运行，直接附加到目标进程上去分析，需要使用AddressSanitizer相关编译选项重新编译代码才行。 

       对于如何在Visual Studio中使用AddressSanitizer内存分析工具，可以看一下微软官方文章的详细说明：

在Visual Studio中集成AddressSanitizerhttps://docs.microsoft.com/zh-cn/cpp/sanitizers/asan?view=msvc-170icon-default.png?t=N7T8https://docs.microsoft.com/zh-cn/cpp/sanitizers/asan?view=msvc-170

3.5.2、Linux平台上内存泄漏的排查 

       在Linux平台上，常用的内存检测工具有Valgrind和AddressSanitizer，这两个工具各有优势。

       Valgrind工具可以直接监测目标进程，不需要重新编译代码，用起来比较方便。但Valgrind在监测内存时比较消耗内存，同时会严重拖慢程序的运行速度，这对于需要实时响应的服务器来讲，是个很大的问题。

       AddressSanitizer是google出品的内存检测工具，gcc4.8及以上版本才内置了AddressSanitizer，通过编译选项去使用该工具（需要重新编译代码），该工具会占用更少的内存，不会明显拖慢程序的运行速度。不过要使用该工具，需要将gcc4.8及以上的版本才行。

       关于AddressSanitizer的优势以及如何使用AddressSanitizer，可以查看我之前写的文章：

为什么选择C/C++内存检测工具AddressSanitizer？如何使用AddressSanitizer？icon-default.png?t=N7T8https://blog.csdn.net/chenlycly/article/details/132863447

4、最后

        上面详细讲解了GDI对象泄漏、进程句柄资源泄漏和内存泄漏三大类问题，希望能给大家提供一定的借鉴和参考。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/96580.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

成功解决@Async注解不生效的问题，异步任务处理问题

成功解决@Async注解不生效的问题，异步任务处理问题

首先&#xff0c;有这样一个异步监听方法 然后配置好了异步线程池 package com.fdw.study.config;import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.ComponentScan; import org.springframework.context.annotation.Conf…
阅读更多...
国产1.8V低电压输入，可用于驱动步进电机；H 桥驱动电路单元可以直接驱动IR-CUT

国产1.8V低电压输入，可用于驱动步进电机；H 桥驱动电路单元可以直接驱动IR-CUT

D6212是专为安防摄像头系统设计的驱动电路&#xff0c;电路由八路达林顿管 阵列和 H 桥驱动电路两个单元组成。八路达林顿管阵列均带有续流二极 管&#xff0c;可用于驱动步进电机&#xff1b;H 桥驱动电路单元可以直接驱动IR-CUT。单个 达林顿管在输入电压低至 1.8V 状态下支持…
阅读更多...
口袋参谋：如何提升宝贝流量？这三种方法超实用！

口袋参谋：如何提升宝贝流量？这三种方法超实用！

​你的店铺能不能出爆款&#xff1f;提升单品流量是关键。 对于新手卖家来说&#xff0c;是缺乏运营技巧和运营经验的&#xff0c;运营技巧主要体现在标题写作、各种图片和视频制作等。 由于新手买家没有经验&#xff0c;习惯于直接使用数据包上传&#xff0c;导致宝贝没有展…
阅读更多...
Java卷上天，可以转行干什么？

Java卷上天，可以转行干什么？

小刚是某名企里的一位有5年经验的高级Java开发工程师&#xff0c;每天沉重的的工作让他疲惫不堪&#xff0c;让他萌生出想换工作的心理&#xff0c;但是转行其他工作他又不清楚该找什么样的工作 因为JAVA 这几年的更新实在是太太太……快了&#xff0c;JAVA 8 都还没用多久&am…
阅读更多...
cpp primer plus笔记01-注意事项

cpp primer plus笔记01-注意事项

cpp尽量以int main()写函数头而不是以main()或者int main(void)或者void main()写。 cpp尽量上图用第4行的注释而不是用第5行注释。 尽量不要引用命名空间比如:using namespace std; 函数体内引用的命名空间会随着函数生命周期结束而失效&#xff0c;放置在全局引用的命名空…
阅读更多...
PX4仿真添加world模型文件，并使用yolov8进行跟踪

PX4仿真添加world模型文件，并使用yolov8进行跟踪

前言 目的：我们是为了在无人机仿真中使用一个汽车模型，然后让仿真的无人机能够识别到这个汽车模型。所以我们需要在无人机仿真的环境中添加汽车模型。 无人机仿真中我们默认使用的empty.world文件，所以只需要将我们需要的模型添加到一起写进这个empty.world文件中去就可以…
阅读更多...
jmeter添加断言（详细图解）

jmeter添加断言（详细图解）

先创建一个线程组&#xff0c;再创建一个http请求。 为了方便观察&#xff0c;我们添加两个监听器&#xff0c;察看结果树和断言结果。 添加断言&#xff1a;响应断言&#xff0c;响应断言也是比较常用的一个断言 设置响应断言&#xff1a;正常情况下响应代码是200。选择响应代…
阅读更多...
Multisim：JFET混频器设计（含完整程序）

Multisim：JFET混频器设计（含完整程序）

目录 前言实验内容一、先看作业题目要求二、作业正文IntroductionPre-lab work3.13.2 Experiment Work4.1(2)circuit setup4.1(3)add 12V DC4.1(4)set input x1 and x24.1(5)4.1(6)4.1(7)4.2(1)(2)4.2(3)4.2(4)4.3(1)(2)4.3(3) Conclusion 三、资源包内容 前言 花了好大心血完成…
阅读更多...
NPDP产品经理知识(产品创新管理)

NPDP产品经理知识(产品创新管理)

复习文化，团队与领导力 产品创新管理： 如何树立愿景： 如何实现产品战略=== 计划 实施产品开发： 商业化，营销计划，推广活动
阅读更多...
1-Java SE基础

1-Java SE基础

Java SE基础知识总结 背景知识 3种技术架构 Java SE&#xff1a;Java Platform Standard Edition&#xff08;标准版&#xff09;&#xff0c;完成桌面应用程序的开发&#xff0c;是其它两者的基础Java ME&#xff1a;Java Platform Micro Edition&#xff0c;开发电子消费产…
阅读更多...
Vue中如何进行分布式任务调度与定时任务管理

Vue中如何进行分布式任务调度与定时任务管理

在Vue中进行分布式任务调度与定时任务管理 分布式任务调度和定时任务管理是许多应用程序中的关键功能之一。它们用于执行周期性的、异步的、重复的任务&#xff0c;例如数据备份、邮件发送、定时报告生成等。在Vue.js应用中&#xff0c;我们可以结合后端服务实现分布式任务调度…
阅读更多...
关于氮化镓的干蚀刻综述

关于氮化镓的干蚀刻综述

引言 GaN及相关合金可用于制造蓝色/绿色/紫外线发射器以及高温、高功率电子器件。由于 III 族氮化物的湿法化学蚀刻结果有限&#xff0c;因此人们投入了大量精力来开发干法蚀刻工艺。干法蚀刻开发一开始集中于台面结构&#xff0c;其中需要高蚀刻速率、各向异性轮廓、光滑侧壁…
阅读更多...
记一次 .NET某账本软件 非托管泄露分析

记一次 .NET某账本软件 非托管泄露分析

一&#xff1a;背景 1. 讲故事 中秋国庆长假结束&#xff0c;哈哈&#xff0c;在老家拍了很多的短视频&#xff0c;有兴趣的可以上B站观看&#xff1a;https://space.bilibili.com/409524162 &#xff0c;今天继续给大家分享各种奇奇怪怪的.NET生产事故&#xff0c;希望能帮助…
阅读更多...
Java基础（二）

Java基础（二）

1. 面向对象基础 1.1 面向对象和面向过程的区别 面向过程把解决问题的过程拆成一个个方法&#xff0c;通过一个个方法的执行解决问题。面向对象会先抽象出对象&#xff0c;然后用对象执行方法的方式解决问题。 面向对象开发的方式更容易维护和迭代升级、易复用、易扩展。 1…
阅读更多...
3D孪生场景搭建：参数化模型

3D孪生场景搭建：参数化模型

1、什么是参数化模型 参数化模型是指通过一组参数来定义其形状和特征的数学模型或几何模型。这些参数可以用于控制模型的大小、形状、比例、位置、旋转、曲率等属性&#xff0c;从而实现对模型进行灵活的调整和变形。 在计算机图形学和三维建模领域&#xff0c;常见的参数化模…
阅读更多...
Docker 镜像的缓存特性

Docker 镜像的缓存特性

Author&#xff1a;rab 目录 前言一、构建缓存二、Pull 缓存总结 前言 首先我们要清楚&#xff0c;Docker 的镜像结构是分层的&#xff0c;镜像本身是只读的&#xff08;不管任何一层&#xff09;&#xff0c;当我们基于某镜像运行一个容器时&#xff0c;会有一个新的可写层被…
阅读更多...
Springboot 音乐网站管理系统idea开发mysql数据库web结构java编程计算机网页源码maven项目

Springboot 音乐网站管理系统idea开发mysql数据库web结构java编程计算机网页源码maven项目

一、源码特点 springboot 音乐网站管理系统是一套完善的信息系统&#xff0c;结合springboot框架和bootstrap完成本系统&#xff0c;对理解JSP java编程开发语言有帮助系统采用springboot框架&#xff08;MVC模式开发&#xff09;&#xff0c;系统 具有完整的源代码和数据库&…
阅读更多...
让丢失成为过去，尽在我们的智能防丢器

让丢失成为过去，尽在我们的智能防丢器

我们都知道&#xff0c;生活中总会遇到一些小烦恼&#xff0c;比如钥匙不见了&#xff0c;钱包忘在哪里&#xff0c;甚至手机掉在了不知名的地方&#xff0c;这些看似小事&#xff0c;却足以打乱我们的日程。那么&#xff0c;有没有一种方法&#xff0c;可以让这些烦恼一扫而空…
阅读更多...
一座“城池”：泡泡玛特主题乐园背后，IP梦想照亮现实

一座“城池”：泡泡玛特主题乐园背后，IP梦想照亮现实

“更适合中国宝宝体质”的主题乐园&#xff0c;被泡泡玛特造出来了。 9月26日&#xff0c;位于北京朝阳公园内的国内首个潮玩行业沉浸式 IP 主题乐园&#xff0c;也是泡泡玛特首个线下乐园——泡泡玛特城市乐园 POP LAND正式开园。 约4万平方米的空间中&#xff0c;泡泡玛特使…
阅读更多...
Javascript - 轮播图

Javascript - 轮播图

轮播图也称banner图、广告图、焦点图、滑片。是指在一个模块或者窗口,通过鼠标点击或手指滑动后,可以看到多张图片。这些图片统称为轮播图,这个模块叫做轮播模块。可以通过运用 javascript去实现定时自动转换图片。以下通过一个小Demo演示如何运用Javascript实现。 <!DOCTYP…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023