bytedeco / javacv

Java interface to OpenCV, FFmpeg, and more
Other
7.57k stars 1.58k forks source link

Java thread can not exit normally #1746

Open 281613520 opened 2 years ago

281613520 commented 2 years ago

In my application, there will be threads that are always executing avcodec_flush_buffer,the stack is as follows "ForkJoinPool.commonPool-worker-0" #22561 daemon prio=5 os_prio=0 tid=0x0000ffff60d3a800 nid=0x7207 runnable [0x0000fffcd953a000] java.lang.Thread.State: RUNNABLE at org.bytedeco.ffmpeg.global.avcodec.avcodec_flush_buffers(Native Method) at org.bytedeco.javacv.FFmpegFrameGrabber.setTimestamp(FFmpegFrameGrabber.java:712)

I also found that some threads will always execute avcodec_free_context,causing other threads to keep waiting to acquire the lock occupied by the lock in this place,the stack is as follows But I found that in this thread, this object (- locked <0x000000055b950f00> (a org.bytedeco.javacv.FFmpegFrameGrabber)) keeps changing, but this thread is still executing this method (avcodec_free_context) "ForkJoinPool.commonPool-worker-5" #22591 daemon prio=5 os_prio=0 tid=0x0000ffff42f18000 nid=0x77c6 runnable [0x0000fffcd8d3b000] java.lang.Thread.State: RUNNABLE at org.bytedeco.ffmpeg.global.avcodec.avcodec_free_context(Native Method) at org.bytedeco.javacv.FFmpegFrameGrabber.releaseUnsafe(FFmpegFrameGrabber.java:206)

"ForkJoinPool.commonPool-worker-8" #22588 daemon prio=5 os_prio=0 tid=0x0000fffb189f9800 nid=0x70ab waiting for monitor entry [0x0000fffcd933a000] java.lang.Thread.State: BLOCKED (on object monitor) at org.bytedeco.javacv.FFmpegFrameGrabber.start(FFmpegFrameGrabber.java:845)

These phenomena have caused the forkjoin thread pool in my entire application to freeze. Can you help analyze this problem?

saudet commented 2 years ago

Did you set a timeout?

281613520 commented 2 years ago

i did not set timeout,how to set this value?

saudet commented 2 years ago

It depends on the protocol, there's a few examples here: https://github.com/bytedeco/javacv/blob/master/samples/FFmpegStreamingTimeout.java

281613520 commented 2 years ago

Is the same solution for the second problem?

saudet commented 2 years ago

You can call startUnsafe() directly instead of start() to avoid the lock.