The address-space your program sees is ALWAYS virtual. (At least in every modern OS.)
You allocate memory by calling the OS API's for that (or the compiler does it for you when you define variables in your code).
The addresses (or pointers, whatever the programming language calls them) you get returned for this allocated memory are valid in the context of your program.
For memory you allocated yourself, you are responsible for returning it to the OS. If the compiler did things on your behalf the compiler will also have included the necessary cleanup.
When your program exits the OS will also do some cleanup.
Where the actual program data resides in the physical RAM of the computer is completely academic. Your OS will map the virtual address space your program sees into the physical RAM and/or swap-space. You yourself simply can't know how that is done at any given time.
It might be important if you are programming a device-driver or a kernel-component, but you obviously don't have the required knowledge about operating systems and programming for that. That much is clear from your question.
Such software operates at a different level and may have to interact with the real physical RAM. There are special methods and API's to deal with that, but you will never encounter those in a normal user-written program.
Another possibility is when you are doing low-level programming on an embedded device where there is no OS to provide this layer of abstraction between virtual and physical RAM. Again: This is something for specialists.
This is simply not something you will ever have to worry about, if you write correct programs by the rules of the programming language.
Of course: If your program is incorrect (e.g. accesses memory it never allocated) the program might crash, or will be terminated by the OS itself, if the OS discovers that the program is misbehaving. Figuring out what went wrong and correcting the problem in the program is an important aspect of programming. It is called debugging.