In addition to the existing answer:
This "simple" question touches a very important topic: memory management. This is even the main "subsystem" of the kernel. "Buy more RAM" is still universally true. But no matter how much you have: every OS has to handle the case where RAM sharing turns into congestion, into swapping, into thrashing.
There is a fine line between efficient use and running out of resources. I went through your numbers and have this interpretation:
"used" shows 83% of "total". That is high. And swap is active; very small, and still with free space.
"free" shows the problem. Less than 1%. Where are the 16%? It's the so called "available", 16 GB here, which is about 16%.
"shared" (4G) plus "buff/cache" (19G) are a bit more than than these "available" 16G -- reflecting the kernel could "sacrifice" two thirds of it. But the way java is running on the system now, this is how it turns out.
So this missing sixth, the x = total - (used+free) (132G - (110+1)), is here 21G, which is between "avail" (16G) and "sh" + "b/c" (23G together).
You have to read
free from left to right, first check "swap", and then ask HOW is it used: as "shared" and/or "buff/cache", and how much of that is "available".
Activation of swap and "free" under 1% show red light, but 16% available and swap details show it is "ok".
(I think the swap is too small for 132G; I hope that java service is also doing something)
This show how it "should" be: enough RAM and a application and OS working together:
Only 5% are used. But 50% are not free. They are used as "shared" and reserved as "buff/cache". Swap is not active. Again, you can't get all of the 61G, but a big part of it.
No use defining new words - it is a matter of interpretation. In the end it is the kernel who knows, and
free is perfect for the top level overview. You have to ask "operator" what he wants, now with this information, or maybe now you even know without asking.