Verson:

JDK21

spring-boot-starter-web 3.5.0

When I upload file to springmvc applicaion, and use MultipartFile#getBytes. it will OOM,If the total size of the attachments I have uploaded exceeds the direct memory size.OOM occurs.

this is the recurrent demo project link https://github.com/sxl-vay/test-direct-memory.git

And I found out that the problem was caused by this commit 4e896c8125c957ffa63238d10444f76d9913b549

Comment From: bclozel

See https://github.com/spring-projects/spring-framework/pull/30155#issuecomment-2945110239

I guess the same could happen with the heap if the parts are too large. I don't understand what's expected of us here. Have you considered using other methods available in MultipartFile to transfer/copy data more efficiently without loading the entire content in memory? I would argue that heap or native memory won't make a difference here: if you allow clients to send very large multipart requests and you're loading the entire contents in memory, this is a potential DoS attack on your application, not a bug in Spring. Please advise.

Comment From: sxl-vay

See #30155 (comment)

I guess the same could happen with the heap if the parts are too large. I don't understand what's expected of us here. Have you considered using other methods available in MultipartFile to transfer/copy data more efficiently without loading the entire content in memory? I would argue that heap or native memory won't make a difference here: if you allow clients to send very large multipart requests and you're loading the entire contents in memory, this is a potential DoS attack on your application, not a bug in Spring. Please advise.

You can take a look at my testing project. I didn't upload a huge file at once, but uploaded files multiple times and called this method multiple times. However, the direct memory occupied by uploading files is not reclaimed, which leads to OOM.

And I when I change jdk to 24.This problem no longer exists.This may also be an issue with JDK

Comment From: sxl-vay

I think I have find the reason

In jdk, this commit fix it :

8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory

commit number: 0312694c46b4fb3455cde2e4d1f8746ad4df8548