Explain this activity monitor screenshot

[thanos.nik]

Hey everyone. I grabbed this screenshot a couple months ago from my 2011 iMac running macOS Sierra. In the minutes leading up to the screenshot the computer was almost completely frozen, so I opened up the activity monitor, but the CPU load was relatively low.. I then switched to the memory tab and saw this:

How can Dashboard be using so much memory (at least ~15GB of which must be virtual) when I'm really not even using it? Also interesting to me are the 121 threads for Dropbox...
Is this a memory leak from Dashboard? I've wondered what it could be but never got around to posting it, so if anyone has an idea of what could be happening your thoughts would be greatly appreciated. It could be a macOS issue that Apple hasn't fixed yet.

 

[BrianBaughn]

I've seen reports of heavy CPU and/or RAM usage with Dashboard. What widgets are installed?

 

[casperes1996]

How can Dashboard be using so much memory (at least ~15GB of which must be virtual) when I'm really not even using it? Also interesting to me are the 121 threads for Dropbox...
Is this a memory leak from Dashboard? I've wondered what it could be but never got around to posting it, so if anyone has an idea of what could be happening your thoughts would be greatly appreciated. It could be a macOS issue that Apple hasn't fixed yet.

Well, Dashboard always behaves nicely for me; I would suspect Dashboard itself is not the culprit, but one of the widgets it contains. What widgets does it run and which are installed?
There's no reasonable explanion it should use that much space unless you have a very unique widget that does some very memory intensive work, but then you'd probably know about it already. And I've never heard of such widget.
The only times I've seen memory usage like that has been with memory leaking bugs, or my own code when I've played around with recursion without a reachable end state.

Regarding the amount of threads an app uses many threads is perfectly reasonable. Every thread doesn't need to have work to do to exist. Dropbox might just have a larger number of threads associated with file synchronization set up such that each can handle a different file or different parts of individual file synchronization jobs most of them just being in an inactive state until an event handler triggers them. Many threads also allows GCD to make more intelligent decisions about workload balancing.

 

[Brian33]

I see my Dropbox has 133 threads right now, so I'm guessing that part is normal.