这是 Windows 堆分配器的一个非常好的特性，从 Vista 开始可用.它告诉你你的代码有一个指针错误.好吧，希望是你的代码而不是 JVM 有错误:) 你***假设它是你的代码.

It is a very nice feature of the Windows heap allocator, available since Vista. It tells you that your code has a pointer bug. Well, hopefully it is your code and not the JVM that has the bug :) You'd better assume it is your code.

实际原因介于轻微之间，比如试图释放已经从另一个堆释放或分配的内存(当你与另一个程序互操作时并不少见)，到非常讨厌，比如通过溢出将堆提前炸成碎片堆分配的缓冲区.

The actual cause ranges somewhere between mild, like trying to free memory that was already freed or allocated from another heap (not uncommon when you interop with another program), to drastically nasty, like having blown the heap to pieces earlier by overflowing a heap allocated buffer.

诊断的粒度不够细，无法准确地告诉您出了什么问题，只是出了点问题.您通常通过仔细的代码审查和人为地禁用代码块来追踪它，直到错误消失.这就是显式内存管理的乐趣.如果 32 位版本是干净的(检查它)，那么由于对指针大小的假设，这可能与 64 位代码相关联.64 位指针不适合 int 或 long，因此它会被截断.使用截断的指针值将触发此断言.这是令人愉快的问题，您会在调用堆栈"窗口中找到故障代码.

The diagnostic is not fine-grained enough to tell you exactly what went wrong, just that there's something wrong. You typically chase it down with a careful code review and artificially disabling chunks of code until the error disappears. Such are the joys of explicit memory management. If the 32-bit version is clean (check it) then this can be associated with 64-bit code due to assumptions about pointer size. A 64-bit pointer doesn't fit in an int or long, so it is going to get truncated. And using the truncated pointer value is going to trigger this assert. That's the happy kind of problem, you'll find the trouble code back in the Call Stack window.