For any RDBMS, the bottleneck for performance is (usually) disk performance. Compared to all other parts of the computer, disk I/O is the most expensive in terms of time required. To this end, RDBMS engines focus on operating on as much data as possible in memory, as RAM is much faster to read and write to than physical disk. It also provides a safety mechanism for ACID compliance, so that only work that is completed successfully will be persisted to disk. If anything is rolled back, either due to failure or manual intervention, it can easily be discarded from memory without affecting the physical storage.
This means that relational engines will try and keep as much data in memory for as long as possible. To continuously push and pull objects from disk to memory is expensive and will hurt application performance. There are times items need to be cycled out of memory, but this will happen based on a LRU algorithm that is designed to keep active data in memory.
It is possible to view information about what is in your cache. Note that the memory pool for SQL Server will contain different objects. Primarily it will be the buffer pool, which stores data objects, and the plan cache, which are the query execution plans. You can utilize specific dynamic management views for this observation, which are used in Glenn Berry's DMV script. Look at queries 39 and 55.
If you wish to restrict the amount of memory SQL Server can use, the only option you really have is to reduce your Max Memory configuration for your instance. Be careful with adjusting this, though, as a reduced memory pool can hamper your performance based on the factors described above.
