gopark | A Naive/Local Go Porting of Spark/DPark

Goroutines are not named. "runtime.gopark" is the package/function where the execution was at the time the debugger stopped the process and took the snapshot of the code execution.

For "runtime.gopark" in particular, this means that the goroutines are temporarily "on hold", paused by the runtime scheduler.

If you wish to get a better insight into the application, and name the goroutines, then you can use a recent version fo the IDE, like 2020.1.2 (or newer), and annotate the code like described in this article.

Why is that happen?

perf tool is doing some kind of searching for binary files. In perf.data there is mmap recorded (seen with perf script -D |grep PERF_RECORD_MMAP2|head command) with path of file mapped with EXEC permission. Main binary file is mapped too, but at moment of mapping the path was relative to the container. In container this file has /bin path as you put it with COPY artifact/bin /. But perf report is started outside the container and tries to resolve /bin path outside of container fs cgroup/namespace. In host system /bin is directory, not file. When you starting perf report while container is still running it may have some heuristics to get executable file with help of /proc/$PID/exe special fs, which probably has success in accessing of files inside container fs namespace.

Is there any solution let perf resolve symbol after container stop ?

I have not too beautiful suggestion (in comments): put the artifact binary into the container at the path which will be equal string to real placement of the binary. For example, if you have the binary as /home/pexie/project1/artifact/bin; in dockerfile create the directory /home/pexie/project1/artifact/ and put the binary into this directory.