If your Mac starts feeling memory-starved whenever Parallels or VMware Fusion is running, even after you've closed the actual Windows or Linux application you needed, that's a well-understood consequence of how virtualization works, not a bug specific to either app.
A VM is a second operating system, with its own memory needs
When you start a virtual machine, you're not just launching an app, you're booting an entire second operating system inside a container that macOS manages. That guest OS, whether it's Windows or a Linux distribution, has its own baseline memory requirements just to run its own kernel, background services, and system processes, entirely separate from anything macOS itself needs. On top of that baseline, whatever software you're actually running inside the VM (a Windows-only application, a specific development environment) adds its own memory needs within the guest.
Both Parallels and VMware Fusion let you configure how much memory to allocate to a VM, and that allocation is reserved for the VM to use while it's running. A VM configured with 8GB allocated genuinely sets aside 8GB of your Mac's total memory for the guest OS to draw on, memory that's then unavailable to macOS and your other Mac apps for as long as the VM is running, regardless of whether the guest OS is actually using all of it at any given moment.
Why it doesn't always release cleanly afterward
In principle, quitting or shutting down a VM should return its allocated memory to macOS for other apps to use. In practice, both Parallels and VMware Fusion have had documented reports, discussed on their own community forums, of memory not being fully released after a VM is stopped, particularly if the VM was suspended (paused into a snapshot-like state) rather than fully shut down, or if the virtualization app itself has been running for a long time across many VM sessions. Suspending a VM instead of shutting it down is convenient, since it lets you resume instantly without a full boot sequence, but it also means the VM's memory allocation can remain reserved in the background even while the VM isn't actively doing anything.
What actually helps
Allocate only as much memory as your VM genuinely needs. Both Parallels and VMware Fusion default to a reasonable allocation based on your Mac's total memory, but if you know your specific Windows or Linux workload doesn't need the full default, reducing it in the VM's settings frees up more headroom for macOS and your other apps whenever the VM is running.
Fully shut down your VM instead of suspending it when you're done for the day. Suspending is faster to resume from, but a full shutdown is far more likely to cleanly release the memory back to macOS, at the cost of a normal boot sequence the next time you need the VM.
Restart the virtualization app itself periodically. If you keep Parallels or VMware Fusion running continuously across many VM sessions over days or weeks, quitting and reopening the app itself (not just the VM) is a reasonable step if you notice memory not being reclaimed as expected, since it clears out any accumulated state in the host-side application.
Only run the VM when you actually need the guest OS. If you're only occasionally reaching for a specific Windows-only tool, keeping the VM shut down the rest of the time avoids the reserved-memory cost entirely outside of when you're actively using it.
Dynamic memory allocation isn't a complete fix
Both Parallels and VMware Fusion offer a dynamic or adaptive memory mode, where the VM's memory allocation is meant to grow and shrink automatically based on what the guest OS is actually using at a given moment, rather than reserving a fixed amount upfront. This genuinely helps compared to a rigid fixed allocation, but it isn't a complete fix for the underlying pattern. Guest operating systems, Windows in particular, tend to hold onto memory they've been given rather than releasing it back proactively, in the same way macOS itself keeps recently used data cached in memory rather than freeing it immediately. That means even with dynamic allocation enabled, a VM that briefly needed a large amount of memory for one task can continue holding much of that allocation afterward, well past the point where the guest OS is actually using it for anything.
A quick way to check what your VM is actually holding
Both apps include their own resource monitoring, Parallels through its Control Center and VMware Fusion through its own VM settings and Activity Monitor-style views, that show you the current memory allocation for a running or suspended VM in real time. Checking this occasionally, particularly if your Mac feels tight on memory and you're not sure whether the VM is the cause, is a faster way to confirm the actual number than guessing from how sluggish things feel.
Where a memory-relief tool fits in
Shiny can't reclaim memory a running VM has deliberately reserved for its guest OS, that allocation is intentional and Parallels or VMware Fusion is managing it correctly while the VM is active. Where Shiny helps is around that: freeing up memory left behind by other apps and background processes on the macOS side, so whatever headroom your Mac has outside the VM's own allocation is being used efficiently, and clearing out anything the virtualization app itself failed to release after you've shut a VM down.
For a related resource-heavy background app pattern, see Docker Desktop's memory usage on Mac, which covers a similar containerized-environment overhead.