1. 线程概念与易语言的线程现状1.1 为什么你的程序会假死做易语言开发的朋友十有八九都遇到过这个场景程序跑起来了点一下按钮开始处理数据结果窗口瞬间变白标题栏显示未响应鼠标移过去转圈圈等个几秒甚至几十秒才恢复。出现这种情况本质上就是主线程被耗时任务占住了。Windows程序默认情况下只有一个主线程所有界面消息的接收和处理都在这个线程里完成。当你在这个线程里执行一个耗时的循环、大量的文件读写或者网络请求时界面消息队列就没人处理了系统以为你的程序挂了于是告诉你未响应。这时候解决办法其实就一句话把耗时任务丢到另一个线程里去跑。1.2 易语言线程开发的常见方式易语言里做多线程大多数新手最先接触的是系统核心库自带的启动线程命令。这个命令确实方便几行代码就能把一个子程序扔到线程里运行。启动线程 (子程序, 参数, 线程ID)但易语言自带的启动线程底层封装得比较厚只暴露了最基础的功能。你想控制线程挂起、恢复、设置栈大小、等待线程结束这些都没法直接做。所以当项目对线程控制要求比较高的时候就得绕开封装直接调用Windows API里的CreateThread函数。这也就是我整理这个511遇见系列里关于API模块的初衷——把常用的Windows API封装成易语言可以直接调用的模块其中CreateThread就是最核心的一个。1.3 CreateThread与易语言启动线程的本质区别先厘清一个概念易语言的启动线程底层调用的就是CreateThread。你可以把易语言的启动线程理解成一个简化版它替你处理了一部分参数默认值但同时也把灵活性给限制住了。CreateThread是Windows提供的原生线程创建API你可以精确控制线程的栈大小、初始状态立即运行还是挂起等待、安全属性还能拿到线程句柄和线程ID。有了句柄你就能对线程做各种操作等待它结束、挂起它、恢复它、查询它的状态。打个比方易语言的启动线程是一键启动API的CreateThread是手动挡每个档位你都能自己掌控。这篇文章接下来的内容就是要带你把手动挡玩明白。2. CreateThread API参数逐项拆解2.1 完整函数签名与易语言声明CreateThread在Windows API中的原型是长这样的HANDLE CreateThread( LPSECURITY_ATTRIBUTES lpThreadAttributes, SIZE_T dwStackSize, LPTHREAD_START_ROUTINE lpStartAddress, LPVOID lpParameter, DWORD dwCreationFlags, LPDWORD lpThreadId );在易语言里DLL命令声明是这个样子.版本 2 .DLL命令 CreateThread, 整数型, kernel32, CreateThread .参数 lpThreadAttributes, 整数型 .参数 dwStackSize, 整数型 .参数 lpStartAddress, 整数型 .参数 lpParameter, 整数型 .参数 dwCreationFlags, 整数型 .参数 lpThreadId, 整数型, 传址注意最后一个参数传址这非常关键。CreateThread需要把创建出来的线程ID写回这个参数如果不加传址你在易语言里永远拿不到线程ID。这一点我见过太多人踩坑了声明的时候忘了传址后面查线程ID怎么都是0。2.2 六个参数的含义与选值逻辑第一个参数lpThreadAttributes线程安全属性。在绝大多数场景下直接传0就行表示使用默认安全描述符子进程不能继承该线程句柄。除非你需要做跨进程的权限控制否则没必要在这方面花心思。第二个参数dwStackSize线程栈大小。传0表示使用系统默认值也就是和主线程一样的大小在64位系统下默认是1MB。栈是线程运行时的临时数据存储区局部变量、函数调用参数都存在这里。如果你的线程函数里使用了超大数组就可能需要手动调整栈大小否则会栈溢出。但99%的情况传0就够了。第三个参数lpStartAddress线程函数的入口地址。这是整个API的核心。在易语言里取子程序地址就是取子程序地址()命令或者直接到整数(子程序名)。这里有个极其重要的限制这个子程序必须位于代码段不能是窗口内的子程序而且必须是一个参数为整数型的子程序。第四个参数lpParameter传给线程函数的参数。线程函数可以接收一个整数型参数这个参数会被系统原封不动地传递给线程入口函数。你可以传0也可以传某个数据的指针。但要注意这个参数在易语言里是整数型如果你要传的是文本或字节集就得先申请内存、把数据写进去、再把指针传过去。第五个参数dwCreationFlags线程创建标志。传0表示线程创建后立即运行传4表示线程创建后处于挂起状态不会被调度执行直到你调用ResumeThread函数。这个标志在你需要先准备好再让线程跑的场景下非常有用。第六个参数lpThreadId输出型参数。这个参数接收系统分配的唯一线程ID方便你在程序里记录和管理。注意区分线程ID和线程句柄线程ID是全局唯一的标识符线程句柄是操作线程的凭证。ID可以用于调试和输出句柄用于等待、控制和关闭。2.3 返回值与错误处理CreateThread返回的是线程句柄如果创建失败则返回0。拿到句柄后操作完毕一定要调用CloseHandle关闭否则会句柄泄漏。每次创建线程泄漏一个句柄短时间看不出来长时间跑的服务型程序很快就会出现句柄耗尽。判断创建是否成功建议这样写.版本 2 .子程序 线程_创建, 整数型, 公开 .参数 线程函数地址, 整数型 .参数 参数指针, 整数型 .局部变量 线程ID, 整数型 .局部变量 线程句柄, 整数型 创建线程立即运行 线程句柄 CreateThread (0, 0, 线程函数地址, 参数指针, 0, 线程ID) 判断是否创建成功 如果真 (线程句柄 0) 返回 (0) 如果真结束 返回线程句柄由调用方负责关闭 返回 (线程句柄)3. 线程函数的设计与书写规范3.1 线程函数的固定格式在易语言中作为线程入口的子程序必须是一个整数型参数、无返回值的子程序。这个约束来自Windows操作系统的底层约定线程入口函数被系统调用时系统会往里压入一个指针参数函数执行完毕后系统期望它调用ExitThread或直接返回。写法是这样的.版本 2 .子程序 线程_入口 .参数 参数指针, 整数型 在这里写线程要执行的任务 比如循环处理数据、下载文件、大量计算等等 任务结束后线程自动退出无需额外操作怎么把这个子程序的地址传给CreateThread呢在易语言里是这样.版本 2 .局部变量 线程句柄, 整数型 .局部变量 线程ID, 整数型 线程句柄 CreateThread (0, 0, 到整数 (线程_入口), 0, 0, 线程ID)这里到整数 (线程_入口)取得的就是线程入口函数的内存地址。需要注意易语言的子程序地址和C语言里的函数指针不完全是一回事但是CreateThread只认地址它把这个地址当作函数入口来调用。易语言的子程序调用约定和CreateThread期望的调用约定在常见的32位编译模式下是可以兼容的。3.2 线程参数传递值与指针的抉择线程函数的那个整数型参数用好了可以传递很多信息。最简单的用法就是传一个具体的数字比如任务编号.版本 2 .子程序 线程_多任务入口 .参数 参数指针, 整数型 参数指针就是任务编号 调试输出 (“线程已启动任务编号” 到文本 (参数指针)) .子程序 线程_启动多个任务 .局部变量 计数器, 整数型 .计次循环首 (10, 计数器) 线程_创建 (到整数 (线程_多任务入口), 计数器) .计次循环尾 ()但如果你要传递的是文本、字节集、自定义数据结构就不能直接传了。这时候标准做法是申请一块内存把数据写进去把内存地址作为参数传给线程线程处理完后再释放内存。这里有一个非常关键的注意事项如果多个线程共用了同一个参数指针每个线程都要根据指针去读数据那就必须确保这块内存在线程运行期间一直有效不能在某个线程里提前释放。3.3 易语言封装好的线程入口模板结合实际操作我整理了一个比较通用的线程入口模板你直接抄作业就行.版本 2 .子程序 线程_任务入口, , , 作为CreateThread的入口 .参数 参数指针, 整数型 .局部变量 数据指针, 整数型 .局部变量 文本内容, 文本型 从指针位置读取数据 如果需要指针转换文本可以用指针到文本 执行具体任务 处理任务 () 任务结束线程自动返回 .子程序 处理任务 这里放你的业务代码用这个模板你只需要把处理任务换成你自己的业务逻辑就能开始用了。4. 线程同步与资源安全4.1 为什么需要线程同步线程一旦跑起来就不是你单线程时代那样一条道走到黑了。多个线程同时访问同一个变量、同一个文件句柄、同一个窗口控件就会产生竞争条件表现为数据错乱、程序崩溃、界面诡异。核心原因在于线程之间的执行顺序是不确定的你不知道哪个线程先跑哪一行代码。易语言虽然底层封装了不少线程相关的支持库但直接使用API创建线程时同步工作全得自己做。如果你不做好同步两个线程同时往一个全局变量里写值结果可能不是你预期的任何一个值而是两个写入操作交错后的脏数据。4.2 临界区是最简单的同步手段临界区Critical Section是同一进程内线程同步效率最高的方式适合保护短小的临界区代码。它的使用模式很固定初始化一个临界区对象、进入临界区、离开临界区、删除临界区。在易语言中使用临界区首先声明相关API.版本 2 .DLL命令 InitializeCriticalSection, , kernel32, InitializeCriticalSection .参数 lpCriticalSection, 整数型 .DLL命令 EnterCriticalSection, , kernel32, EnterCriticalSection .参数 lpCriticalSection, 整数型 .DLL命令 LeaveCriticalSection, , kernel32, LeaveCriticalSection .参数 lpCriticalSection, 整数型 .DLL命令 DeleteCriticalSection, , kernel32, DeleteCriticalSection .参数 lpCriticalSection, 整数型然后在使用时定义一个全局变量存储临界区对象内存程序启动时初始化访问共享数据前Enter访问完Leave程序退出前Delete。这里必须提醒一点易语言中临界区对象不是直接定义一个变量就能用的你需要申请内存来存放临界区结构体。常见的做法是使用申请内存命令开辟一块空间把地址传给API。.版本 2 .全局变量 临界区指针, 整数型 .子程序 程序_初始化同步 临界区指针 申请内存 (64, 真) InitializeCriticalSection (临界区指针) .子程序 程序_释放同步 DeleteCriticalSection (临界区指针) 释放内存 (临界区指针)后面的代码在访问共享数据时只需要包裹Enter/Leave即可。这个方案我实测下来非常稳性能损耗极小。4.3 互斥量与事件对象的选择临界区有一个限制它只能同步同一进程内的线程。如果你需要跨进程同步或者需要在等待资源时设置超时时间就要用互斥量Mutex。互斥量的创建和等待依赖CreateMutex、WaitForSingleObject、ReleaseMutex这组API。和临界区最大的区别是互斥量是内核对象性能上比临界区慢一些但可以在不同进程之间工作。另一种常用同步手段是事件对象Event特别适合一个线程干活另一个线程等待活干完了再继续的场景。用CreateEvent创建事件用SetEvent设置事件为有信号状态用WaitForSingleObject等待事件触发。.版本 2 .DLL命令 CreateEventA, 整数型, kernel32, CreateEventA .参数 lpEventAttributes, 整数型 .参数 bManualReset, 整数型 .参数 bInitialState, 整数型 .参数 lpName, 整数型事件对象最常见的使用模式是主线程创建事件工作线程等待事件信号后再开始执行主线程处理好初始数据后SetEvent放行。这种模式可以完美替代线程挂起后再恢复的复杂控制。4.4 线程退出与内存管理CreateThread创建出来的线程退出方式有两种线程函数自然返回或者线程内部调用ExitThread。自然返回是推荐方式因为这样C运行时库有机会执行清理工作。这里要特别强调线程里申请的内存线程结束时不会自动释放。你必须自己保证每一条申请路径都有对应的释放路径。一个很常见的BUG就是线程函数内部申请了内存中途出了个分支提前返回了释放内存的代码没执行结果每次跑这个任务都泄漏一点内存。我的习惯是把线程函数的所有逻辑包在一个整体异常捕获结构里确保无论哪个分支出错都能走到释放内存的环节。易语言有强制退出保护命令可以配合使用。5. 封装成可复用的API线程模块5.1 模块的整体设计思路511遇见这个系列的核心价值就是把零散的API调用封装成易语言模块让使用者不需要关心底层细节。所以封装CreateThread时也要遵循这个思路外部只需要调用一个命令传入线程函数地址和参数就能拿到线程句柄其他细节模块内部处理。我设计的模块功能包括创建线程、创建挂起线程、恢复线程、等待线程、强制结束线程、关闭句柄。5.2 完整的线程模块源码下面是我实际在用的一个封装模块核心代码.版本 2 .DLL命令 CreateThread, 整数型, kernel32, CreateThread .参数 lpThreadAttributes, 整数型 .参数 dwStackSize, 整数型 .参数 lpStartAddress, 整数型 .参数 lpParameter, 整数型 .参数 dwCreationFlags, 整数型 .参数 lpThreadId, 整数型, 传址 .DLL命令 ResumeThread, 整数型, kernel32, ResumeThread .参数 hThread, 整数型 .DLL命令 WaitForSingleObject, 整数型, kernel32, WaitForSingleObject .参数 hHandle, 整数型 .参数 dwMilliseconds, 整数型 .DLL命令 CloseHandle, 整数型, kernel32, CloseHandle .参数 hObject, 整数型 .DLL命令 TerminateThread, 整数型, kernel32, TerminateThread .参数 hThread, 整数型 .参数 dwExitCode, 整数型 .子程序 线程_创建, 整数型, 公开 .参数 线程函数地址, 整数型 .参数 参数指针, 整数型, 可空 .参数 线程ID, 整数型, 参考, 可空 .局部变量 lThreadId, 整数型 .局部变量 hThread, 整数型 创建并立即启动线程 hThread CreateThread (0, 0, 线程函数地址, 参数指针, 0, lThreadId) 线程ID lThreadId 返回 (hThread) .子程序 线程_创建挂起, 整数型, 公开 .参数 线程函数地址, 整数型 .参数 参数指针, 整数型, 可空 .参数 线程ID, 整数型, 参考, 可空 .局部变量 lThreadId, 整数型 .局部变量 hThread, 整数型 创建线程初始挂起 hThread CreateThread (0, 0, 线程函数地址, 参数指针, 4, lThreadId) 线程ID lThreadId 返回 (hThread) .子程序 线程_恢复, 整数型, 公开 .参数 线程句柄, 整数型 调用ResumeThread返回值是线程之前的挂起计数 返回 (ResumeThread (线程句柄)) .子程序 线程_等待结束, 逻辑型, 公开 .参数 线程句柄, 整数型 .参数 超时时间, 整数型, 可空 .局部变量 结果, 整数型 第二个参数传-1表示无限等待 结果 WaitForSingleObject (线程句柄, 超时时间) 返回 (结果 0) .子程序 线程_强制结束, 逻辑型, 公开 .参数 线程句柄, 整数型 .参数 退出码, 整数型, 可空 强制结束线程谨慎使用 返回 (TerminateThread (线程句柄, 退出码) ≠ 0) .子程序 线程_关闭句柄, 逻辑型, 公开 .参数 线程句柄, 整数型 关闭句柄释放内核对象引用 返回 (CloseHandle (线程句柄) ≠ 0)5.3 模块的易用性设计细节这个模块在封装时我特意做了几个优化。第一参数指针设为可空这样只创建线程不传参数时调用方不用纠结填0还是什么都不填。第二线程ID直接通过参考参数返回外部不用自己声明传递地址。第三等待线程时超时时间可空默认用无限等待但外部也可以设置为具体毫秒值避免线程内部卡死导致主程序也卡住。提示WaitForSingleObject的第二个参数传-1表示无限期等待传0表示立即检查并返回传正数表示最多等待多少毫秒。实际开发中如果不确定线程内部会不会卡死建议设置一个合理的超时时间比如3000毫秒这样线程故障时主流程还能继续跑。6. 实际使用中的避坑记录6.1 线程函数地址获取错误这是新手最容易犯的错误。取子程序地址时如果你取的是一个有参数且有返回值的子程序或者取的是窗口的方法子程序结果往往不对。CreateThread期望的是一个CALLBACK类型的函数地址易语言里只有无返回值、单个整数型参数的子程序才符合这个约定。如果取地址取错了线程创建可能失败也可能线程一启动就崩溃。我曾经见过有人取了一个参数类型为文本型的子程序地址结果线程一跑就报内存访问错误。原因很简单系统压入的参数实际上是一个整型指针而子程序声明的是文本型参数两边对不上数据就被强行解释了。6.2 界面操作必须回到主线程子线程里直接操作窗口控件在易语言里是一个非常常见的崩溃来源。虽然有些情况下看起来能运行但本质上是未定义行为偶尔能跑通偶尔就崩了。正确做法是子线程干完活把结果通过消息或者标志位传给主线程由主线程去更新界面。或者使用易语言的发送消息命令把自定义消息发到窗口窗口在消息处理函数里更新界面。6.3 线程句柄不关闭导致泄漏每次创建线程拿到的句柄如果一直不关闭随着程序运行会堆积大量内核句柄。Windows对单个进程的句柄数量有限制虽然默认值不低但长时间跑的服务型程序迟早会撞上限。我的建议是创建线程后如果需要等待这个线程结束就保留句柄如果不关心线程何时结束直接创建完就关闭句柄。关闭句柄不会结束线程线程自己还能继续跑只是你失去了对它的控制权。 创建线程后立即关闭句柄线程照常运行 .局部变量 线程句柄, 整数型 .局部变量 线程ID, 整数型 线程句柄 线程_创建 (到整数 (线程_入口), 0, 线程ID) 线程_关闭句柄 (线程句柄)6.4 无限循环线程的退出策略有些线程是一直跑的循环结构比如监听网络数据、监控某个目录的变化。这种线程如果直接强制结束TerminateThread可能导致资源没释放锁没解开大麻烦在后面。更优雅的做法是设置一个退出标志.版本 2 .全局变量 全局_退出标志, 逻辑型 .子程序 线程_循环入口 .参数 参数指针, 整数型 .判断循环首 (真) 如果真 (全局_退出标志) 跳出循环 如果真结束 执行具体工作 工作完毕后让出CPU时间片 程序_延时 (10) .判断循环尾 () .子程序 程序_请求退出 全局_退出标志 真这样主线程只需要设置标志为真工作线程会在下一个循环周期自己退出安全又干净。6.5 调试线程程序的独门技巧线程程序调试比普通程序麻烦得多单步跟踪线程内部状态往往不靠谱因为线程是并发执行的你停下这个线程其他线程还在跑。我的经验是多使用调试输出把关键节点和变量值都输出到调试控制台。另外线程崩溃时Windows可能直接让整个进程退出不会给你机会看到错误弹窗。这种情况建议先把线程函数里的代码打上日志缩小排查范围定位到具体崩溃位置再修复。7. 模块扩展方向与后续玩法7.1 线程池化的实现思路有了这个线程创建模块后面就可以做更有意思的事。比如线程池预先创建一批线程任务来了分配给空闲线程执行任务执行完线程不退出、继续等待下一个任务。线程池能显著降低反复创建线程带来的性能开销因为线程创建和销毁本身是有代价的。实现线程池的核心是任务队列和空闲线程管理。用这个CreateThread模块配合队列数据结构和事件对象就能拼出一个简易线程池。7.2 多线程并发下载场景我实际用这套模块写过一个并发文件下载器。思路是把一个文件按大小切分成多个块每个块一个线程去下载全部线程完成后主线程把各块拼回完整文件。用CreateThread的好处是创建线程时指定线程ID每个线程对应自己的块号排查问题非常方便。下载器的核心是一个线程完成计数器每完成一个块就加一等计数器等于总块数时通知主线程合并文件。这里用到了临界区保护计数器自增操作。7.3 与易语言其他多线程库的共存问题用了API创建线程后再用易语言核心库的启动线程需要注意易语言部分命令内部有自己的线程局部存储机制。如果两者混用某些场景下可能出现奇怪的问题。我的建议是一个项目里统一使用一套方案要么全用API要么全用核心库不要混着来。实测中混用启动线程和CreateThread后在线程里调用易语言的取当前时间等命令时偶尔会出错排查很久才定位到是混用导致。从那以后我就养成了统一方案的习惯。最后再分享一点个人体会。做易语言开发很多朋友被API太难吓住了实际上把CreateThread这类的核心API吃透以后你会发现它能干的事情远超想象。而且一旦跨过这个门槛再去看其他API就会豁然开朗因为DLL调用的基本套路是相通的。建议你拿到这个模块后先写一个最简单的递增计数器线程练手然后逐步加入挂起、恢复、等待、同步这些功能把每个API参数的含义和返回值都吃透后面遇到复杂项目就会非常顺手。 
长河君 · 2026/10/16 7:48:22 · 阅读 1.2k 易语言多线程编程：CreateThread API详解与线程同步实践
1. 线程概念与易语言的线程现状1.1 为什么你的程序会假死做易语言开发的朋友十有八九都遇到过这个场景程序跑起来了点一下按钮开始处理数据结果窗口瞬间变白标题栏显示未响应鼠标移过去转圈圈等个几秒甚至几十秒才恢复。出现这种情况本质上就是主线程被耗时任务占住了。Windows程序默认情况下只有一个主线程所有界面消息的接收和处理都在这个线程里完成。当你在这个线程里执行一个耗时的循环、大量的文件读写或者网络请求时界面消息队列就没人处理了系统以为你的程序挂了于是告诉你未响应。这时候解决办法其实就一句话把耗时任务丢到另一个线程里去跑。1.2 易语言线程开发的常见方式易语言里做多线程大多数新手最先接触的是系统核心库自带的启动线程命令。这个命令确实方便几行代码就能把一个子程序扔到线程里运行。启动线程 (子程序, 参数, 线程ID)但易语言自带的启动线程底层封装得比较厚只暴露了最基础的功能。你想控制线程挂起、恢复、设置栈大小、等待线程结束这些都没法直接做。所以当项目对线程控制要求比较高的时候就得绕开封装直接调用Windows API里的CreateThread函数。这也就是我整理这个511遇见系列里关于API模块的初衷——把常用的Windows API封装成易语言可以直接调用的模块其中CreateThread就是最核心的一个。1.3 CreateThread与易语言启动线程的本质区别先厘清一个概念易语言的启动线程底层调用的就是CreateThread。你可以把易语言的启动线程理解成一个简化版它替你处理了一部分参数默认值但同时也把灵活性给限制住了。CreateThread是Windows提供的原生线程创建API你可以精确控制线程的栈大小、初始状态立即运行还是挂起等待、安全属性还能拿到线程句柄和线程ID。有了句柄你就能对线程做各种操作等待它结束、挂起它、恢复它、查询它的状态。打个比方易语言的启动线程是一键启动API的CreateThread是手动挡每个档位你都能自己掌控。这篇文章接下来的内容就是要带你把手动挡玩明白。2. CreateThread API参数逐项拆解2.1 完整函数签名与易语言声明CreateThread在Windows API中的原型是长这样的HANDLE CreateThread( LPSECURITY_ATTRIBUTES lpThreadAttributes, SIZE_T dwStackSize, LPTHREAD_START_ROUTINE lpStartAddress, LPVOID lpParameter, DWORD dwCreationFlags, LPDWORD lpThreadId );在易语言里DLL命令声明是这个样子.版本 2 .DLL命令 CreateThread, 整数型, kernel32, CreateThread .参数 lpThreadAttributes, 整数型 .参数 dwStackSize, 整数型 .参数 lpStartAddress, 整数型 .参数 lpParameter, 整数型 .参数 dwCreationFlags, 整数型 .参数 lpThreadId, 整数型, 传址注意最后一个参数传址这非常关键。CreateThread需要把创建出来的线程ID写回这个参数如果不加传址你在易语言里永远拿不到线程ID。这一点我见过太多人踩坑了声明的时候忘了传址后面查线程ID怎么都是0。2.2 六个参数的含义与选值逻辑第一个参数lpThreadAttributes线程安全属性。在绝大多数场景下直接传0就行表示使用默认安全描述符子进程不能继承该线程句柄。除非你需要做跨进程的权限控制否则没必要在这方面花心思。第二个参数dwStackSize线程栈大小。传0表示使用系统默认值也就是和主线程一样的大小在64位系统下默认是1MB。栈是线程运行时的临时数据存储区局部变量、函数调用参数都存在这里。如果你的线程函数里使用了超大数组就可能需要手动调整栈大小否则会栈溢出。但99%的情况传0就够了。第三个参数lpStartAddress线程函数的入口地址。这是整个API的核心。在易语言里取子程序地址就是取子程序地址()命令或者直接到整数(子程序名)。这里有个极其重要的限制这个子程序必须位于代码段不能是窗口内的子程序而且必须是一个参数为整数型的子程序。第四个参数lpParameter传给线程函数的参数。线程函数可以接收一个整数型参数这个参数会被系统原封不动地传递给线程入口函数。你可以传0也可以传某个数据的指针。但要注意这个参数在易语言里是整数型如果你要传的是文本或字节集就得先申请内存、把数据写进去、再把指针传过去。第五个参数dwCreationFlags线程创建标志。传0表示线程创建后立即运行传4表示线程创建后处于挂起状态不会被调度执行直到你调用ResumeThread函数。这个标志在你需要先准备好再让线程跑的场景下非常有用。第六个参数lpThreadId输出型参数。这个参数接收系统分配的唯一线程ID方便你在程序里记录和管理。注意区分线程ID和线程句柄线程ID是全局唯一的标识符线程句柄是操作线程的凭证。ID可以用于调试和输出句柄用于等待、控制和关闭。2.3 返回值与错误处理CreateThread返回的是线程句柄如果创建失败则返回0。拿到句柄后操作完毕一定要调用CloseHandle关闭否则会句柄泄漏。每次创建线程泄漏一个句柄短时间看不出来长时间跑的服务型程序很快就会出现句柄耗尽。判断创建是否成功建议这样写.版本 2 .子程序 线程_创建, 整数型, 公开 .参数 线程函数地址, 整数型 .参数 参数指针, 整数型 .局部变量 线程ID, 整数型 .局部变量 线程句柄, 整数型 创建线程立即运行 线程句柄 CreateThread (0, 0, 线程函数地址, 参数指针, 0, 线程ID) 判断是否创建成功 如果真 (线程句柄 0) 返回 (0) 如果真结束 返回线程句柄由调用方负责关闭 返回 (线程句柄)3. 线程函数的设计与书写规范3.1 线程函数的固定格式在易语言中作为线程入口的子程序必须是一个整数型参数、无返回值的子程序。这个约束来自Windows操作系统的底层约定线程入口函数被系统调用时系统会往里压入一个指针参数函数执行完毕后系统期望它调用ExitThread或直接返回。写法是这样的.版本 2 .子程序 线程_入口 .参数 参数指针, 整数型 在这里写线程要执行的任务 比如循环处理数据、下载文件、大量计算等等 任务结束后线程自动退出无需额外操作怎么把这个子程序的地址传给CreateThread呢在易语言里是这样.版本 2 .局部变量 线程句柄, 整数型 .局部变量 线程ID, 整数型 线程句柄 CreateThread (0, 0, 到整数 (线程_入口), 0, 0, 线程ID)这里到整数 (线程_入口)取得的就是线程入口函数的内存地址。需要注意易语言的子程序地址和C语言里的函数指针不完全是一回事但是CreateThread只认地址它把这个地址当作函数入口来调用。易语言的子程序调用约定和CreateThread期望的调用约定在常见的32位编译模式下是可以兼容的。3.2 线程参数传递值与指针的抉择线程函数的那个整数型参数用好了可以传递很多信息。最简单的用法就是传一个具体的数字比如任务编号.版本 2 .子程序 线程_多任务入口 .参数 参数指针, 整数型 参数指针就是任务编号 调试输出 (“线程已启动任务编号” 到文本 (参数指针)) .子程序 线程_启动多个任务 .局部变量 计数器, 整数型 .计次循环首 (10, 计数器) 线程_创建 (到整数 (线程_多任务入口), 计数器) .计次循环尾 ()但如果你要传递的是文本、字节集、自定义数据结构就不能直接传了。这时候标准做法是申请一块内存把数据写进去把内存地址作为参数传给线程线程处理完后再释放内存。这里有一个非常关键的注意事项如果多个线程共用了同一个参数指针每个线程都要根据指针去读数据那就必须确保这块内存在线程运行期间一直有效不能在某个线程里提前释放。3.3 易语言封装好的线程入口模板结合实际操作我整理了一个比较通用的线程入口模板你直接抄作业就行.版本 2 .子程序 线程_任务入口, , , 作为CreateThread的入口 .参数 参数指针, 整数型 .局部变量 数据指针, 整数型 .局部变量 文本内容, 文本型 从指针位置读取数据 如果需要指针转换文本可以用指针到文本 执行具体任务 处理任务 () 任务结束线程自动返回 .子程序 处理任务 这里放你的业务代码用这个模板你只需要把处理任务换成你自己的业务逻辑就能开始用了。4. 线程同步与资源安全4.1 为什么需要线程同步线程一旦跑起来就不是你单线程时代那样一条道走到黑了。多个线程同时访问同一个变量、同一个文件句柄、同一个窗口控件就会产生竞争条件表现为数据错乱、程序崩溃、界面诡异。核心原因在于线程之间的执行顺序是不确定的你不知道哪个线程先跑哪一行代码。易语言虽然底层封装了不少线程相关的支持库但直接使用API创建线程时同步工作全得自己做。如果你不做好同步两个线程同时往一个全局变量里写值结果可能不是你预期的任何一个值而是两个写入操作交错后的脏数据。4.2 临界区是最简单的同步手段临界区Critical Section是同一进程内线程同步效率最高的方式适合保护短小的临界区代码。它的使用模式很固定初始化一个临界区对象、进入临界区、离开临界区、删除临界区。在易语言中使用临界区首先声明相关API.版本 2 .DLL命令 InitializeCriticalSection, , kernel32, InitializeCriticalSection .参数 lpCriticalSection, 整数型 .DLL命令 EnterCriticalSection, , kernel32, EnterCriticalSection .参数 lpCriticalSection, 整数型 .DLL命令 LeaveCriticalSection, , kernel32, LeaveCriticalSection .参数 lpCriticalSection, 整数型 .DLL命令 DeleteCriticalSection, , kernel32, DeleteCriticalSection .参数 lpCriticalSection, 整数型然后在使用时定义一个全局变量存储临界区对象内存程序启动时初始化访问共享数据前Enter访问完Leave程序退出前Delete。这里必须提醒一点易语言中临界区对象不是直接定义一个变量就能用的你需要申请内存来存放临界区结构体。常见的做法是使用申请内存命令开辟一块空间把地址传给API。.版本 2 .全局变量 临界区指针, 整数型 .子程序 程序_初始化同步 临界区指针 申请内存 (64, 真) InitializeCriticalSection (临界区指针) .子程序 程序_释放同步 DeleteCriticalSection (临界区指针) 释放内存 (临界区指针)后面的代码在访问共享数据时只需要包裹Enter/Leave即可。这个方案我实测下来非常稳性能损耗极小。4.3 互斥量与事件对象的选择临界区有一个限制它只能同步同一进程内的线程。如果你需要跨进程同步或者需要在等待资源时设置超时时间就要用互斥量Mutex。互斥量的创建和等待依赖CreateMutex、WaitForSingleObject、ReleaseMutex这组API。和临界区最大的区别是互斥量是内核对象性能上比临界区慢一些但可以在不同进程之间工作。另一种常用同步手段是事件对象Event特别适合一个线程干活另一个线程等待活干完了再继续的场景。用CreateEvent创建事件用SetEvent设置事件为有信号状态用WaitForSingleObject等待事件触发。.版本 2 .DLL命令 CreateEventA, 整数型, kernel32, CreateEventA .参数 lpEventAttributes, 整数型 .参数 bManualReset, 整数型 .参数 bInitialState, 整数型 .参数 lpName, 整数型事件对象最常见的使用模式是主线程创建事件工作线程等待事件信号后再开始执行主线程处理好初始数据后SetEvent放行。这种模式可以完美替代线程挂起后再恢复的复杂控制。4.4 线程退出与内存管理CreateThread创建出来的线程退出方式有两种线程函数自然返回或者线程内部调用ExitThread。自然返回是推荐方式因为这样C运行时库有机会执行清理工作。这里要特别强调线程里申请的内存线程结束时不会自动释放。你必须自己保证每一条申请路径都有对应的释放路径。一个很常见的BUG就是线程函数内部申请了内存中途出了个分支提前返回了释放内存的代码没执行结果每次跑这个任务都泄漏一点内存。我的习惯是把线程函数的所有逻辑包在一个整体异常捕获结构里确保无论哪个分支出错都能走到释放内存的环节。易语言有强制退出保护命令可以配合使用。5. 封装成可复用的API线程模块5.1 模块的整体设计思路511遇见这个系列的核心价值就是把零散的API调用封装成易语言模块让使用者不需要关心底层细节。所以封装CreateThread时也要遵循这个思路外部只需要调用一个命令传入线程函数地址和参数就能拿到线程句柄其他细节模块内部处理。我设计的模块功能包括创建线程、创建挂起线程、恢复线程、等待线程、强制结束线程、关闭句柄。5.2 完整的线程模块源码下面是我实际在用的一个封装模块核心代码.版本 2 .DLL命令 CreateThread, 整数型, kernel32, CreateThread .参数 lpThreadAttributes, 整数型 .参数 dwStackSize, 整数型 .参数 lpStartAddress, 整数型 .参数 lpParameter, 整数型 .参数 dwCreationFlags, 整数型 .参数 lpThreadId, 整数型, 传址 .DLL命令 ResumeThread, 整数型, kernel32, ResumeThread .参数 hThread, 整数型 .DLL命令 WaitForSingleObject, 整数型, kernel32, WaitForSingleObject .参数 hHandle, 整数型 .参数 dwMilliseconds, 整数型 .DLL命令 CloseHandle, 整数型, kernel32, CloseHandle .参数 hObject, 整数型 .DLL命令 TerminateThread, 整数型, kernel32, TerminateThread .参数 hThread, 整数型 .参数 dwExitCode, 整数型 .子程序 线程_创建, 整数型, 公开 .参数 线程函数地址, 整数型 .参数 参数指针, 整数型, 可空 .参数 线程ID, 整数型, 参考, 可空 .局部变量 lThreadId, 整数型 .局部变量 hThread, 整数型 创建并立即启动线程 hThread CreateThread (0, 0, 线程函数地址, 参数指针, 0, lThreadId) 线程ID lThreadId 返回 (hThread) .子程序 线程_创建挂起, 整数型, 公开 .参数 线程函数地址, 整数型 .参数 参数指针, 整数型, 可空 .参数 线程ID, 整数型, 参考, 可空 .局部变量 lThreadId, 整数型 .局部变量 hThread, 整数型 创建线程初始挂起 hThread CreateThread (0, 0, 线程函数地址, 参数指针, 4, lThreadId) 线程ID lThreadId 返回 (hThread) .子程序 线程_恢复, 整数型, 公开 .参数 线程句柄, 整数型 调用ResumeThread返回值是线程之前的挂起计数 返回 (ResumeThread (线程句柄)) .子程序 线程_等待结束, 逻辑型, 公开 .参数 线程句柄, 整数型 .参数 超时时间, 整数型, 可空 .局部变量 结果, 整数型 第二个参数传-1表示无限等待 结果 WaitForSingleObject (线程句柄, 超时时间) 返回 (结果 0) .子程序 线程_强制结束, 逻辑型, 公开 .参数 线程句柄, 整数型 .参数 退出码, 整数型, 可空 强制结束线程谨慎使用 返回 (TerminateThread (线程句柄, 退出码) ≠ 0) .子程序 线程_关闭句柄, 逻辑型, 公开 .参数 线程句柄, 整数型 关闭句柄释放内核对象引用 返回 (CloseHandle (线程句柄) ≠ 0)5.3 模块的易用性设计细节这个模块在封装时我特意做了几个优化。第一参数指针设为可空这样只创建线程不传参数时调用方不用纠结填0还是什么都不填。第二线程ID直接通过参考参数返回外部不用自己声明传递地址。第三等待线程时超时时间可空默认用无限等待但外部也可以设置为具体毫秒值避免线程内部卡死导致主程序也卡住。提示WaitForSingleObject的第二个参数传-1表示无限期等待传0表示立即检查并返回传正数表示最多等待多少毫秒。实际开发中如果不确定线程内部会不会卡死建议设置一个合理的超时时间比如3000毫秒这样线程故障时主流程还能继续跑。6. 实际使用中的避坑记录6.1 线程函数地址获取错误这是新手最容易犯的错误。取子程序地址时如果你取的是一个有参数且有返回值的子程序或者取的是窗口的方法子程序结果往往不对。CreateThread期望的是一个CALLBACK类型的函数地址易语言里只有无返回值、单个整数型参数的子程序才符合这个约定。如果取地址取错了线程创建可能失败也可能线程一启动就崩溃。我曾经见过有人取了一个参数类型为文本型的子程序地址结果线程一跑就报内存访问错误。原因很简单系统压入的参数实际上是一个整型指针而子程序声明的是文本型参数两边对不上数据就被强行解释了。6.2 界面操作必须回到主线程子线程里直接操作窗口控件在易语言里是一个非常常见的崩溃来源。虽然有些情况下看起来能运行但本质上是未定义行为偶尔能跑通偶尔就崩了。正确做法是子线程干完活把结果通过消息或者标志位传给主线程由主线程去更新界面。或者使用易语言的发送消息命令把自定义消息发到窗口窗口在消息处理函数里更新界面。6.3 线程句柄不关闭导致泄漏每次创建线程拿到的句柄如果一直不关闭随着程序运行会堆积大量内核句柄。Windows对单个进程的句柄数量有限制虽然默认值不低但长时间跑的服务型程序迟早会撞上限。我的建议是创建线程后如果需要等待这个线程结束就保留句柄如果不关心线程何时结束直接创建完就关闭句柄。关闭句柄不会结束线程线程自己还能继续跑只是你失去了对它的控制权。 创建线程后立即关闭句柄线程照常运行 .局部变量 线程句柄, 整数型 .局部变量 线程ID, 整数型 线程句柄 线程_创建 (到整数 (线程_入口), 0, 线程ID) 线程_关闭句柄 (线程句柄)6.4 无限循环线程的退出策略有些线程是一直跑的循环结构比如监听网络数据、监控某个目录的变化。这种线程如果直接强制结束TerminateThread可能导致资源没释放锁没解开大麻烦在后面。更优雅的做法是设置一个退出标志.版本 2 .全局变量 全局_退出标志, 逻辑型 .子程序 线程_循环入口 .参数 参数指针, 整数型 .判断循环首 (真) 如果真 (全局_退出标志) 跳出循环 如果真结束 执行具体工作 工作完毕后让出CPU时间片 程序_延时 (10) .判断循环尾 () .子程序 程序_请求退出 全局_退出标志 真这样主线程只需要设置标志为真工作线程会在下一个循环周期自己退出安全又干净。6.5 调试线程程序的独门技巧线程程序调试比普通程序麻烦得多单步跟踪线程内部状态往往不靠谱因为线程是并发执行的你停下这个线程其他线程还在跑。我的经验是多使用调试输出把关键节点和变量值都输出到调试控制台。另外线程崩溃时Windows可能直接让整个进程退出不会给你机会看到错误弹窗。这种情况建议先把线程函数里的代码打上日志缩小排查范围定位到具体崩溃位置再修复。7. 模块扩展方向与后续玩法7.1 线程池化的实现思路有了这个线程创建模块后面就可以做更有意思的事。比如线程池预先创建一批线程任务来了分配给空闲线程执行任务执行完线程不退出、继续等待下一个任务。线程池能显著降低反复创建线程带来的性能开销因为线程创建和销毁本身是有代价的。实现线程池的核心是任务队列和空闲线程管理。用这个CreateThread模块配合队列数据结构和事件对象就能拼出一个简易线程池。7.2 多线程并发下载场景我实际用这套模块写过一个并发文件下载器。思路是把一个文件按大小切分成多个块每个块一个线程去下载全部线程完成后主线程把各块拼回完整文件。用CreateThread的好处是创建线程时指定线程ID每个线程对应自己的块号排查问题非常方便。下载器的核心是一个线程完成计数器每完成一个块就加一等计数器等于总块数时通知主线程合并文件。这里用到了临界区保护计数器自增操作。7.3 与易语言其他多线程库的共存问题用了API创建线程后再用易语言核心库的启动线程需要注意易语言部分命令内部有自己的线程局部存储机制。如果两者混用某些场景下可能出现奇怪的问题。我的建议是一个项目里统一使用一套方案要么全用API要么全用核心库不要混着来。实测中混用启动线程和CreateThread后在线程里调用易语言的取当前时间等命令时偶尔会出错排查很久才定位到是混用导致。从那以后我就养成了统一方案的习惯。最后再分享一点个人体会。做易语言开发很多朋友被API太难吓住了实际上把CreateThread这类的核心API吃透以后你会发现它能干的事情远超想象。而且一旦跨过这个门槛再去看其他API就会豁然开朗因为DLL调用的基本套路是相通的。建议你拿到这个模块后先写一个最简单的递增计数器线程练手然后逐步加入挂起、恢复、等待、同步这些功能把每个API参数的含义和返回值都吃透后面遇到复杂项目就会非常顺手。