Case 1 If your application allows the user to serialize information (e.g. by producing a file which can be manipulated with the file system and other applications), always offer a manual save. And instead of an autosave on close, offer a restore-on-open-after-close-without-saving which does not overwrite the user's file by default. Example: Microsoft Word.
The reason for that: in this case, the user wants to own her information, and to reuse it outside of your application, or at least outside of the application instance which produced it. And while she would hate to lose information in a crash, she would also hate it when she tries some changes, doesn't like them, and finds out that closing without saving does not work to revert her changes. (Yes, we'd all have an easier time if users would use version control systems for all of their documents. But they don't.)
Case 2 If your application manages data, but doesn't allow the user to serialize it (iPad applications and many cloud applications work this way), use autosave on close. You may add a save button for the secure feeling or, on a web application, for cases where the server side of the application may not detect the change immediately. Example: Evernote.
A note on this second case: I can confirm that many users dislike this model, there is close to zero acceptance for it for a cloud application with a desktop client frontend. In 2012, I ran two separate studies getting users to vote on proposed features of an application, and adopting this model was the one most hated feature of all proposed ones in both studies. Some applications can pull it off, especially games, without losing acceptance, but in the general case, it is an uphill battle. It is much more accepted in cloud solutions with a web frontend (example: Remember the milk), or in a mobile context, including Android - despite the fact that it is possible to serialize data as files on Android. If you are going to follow this model, a Save button will really appease your users even if it does nothing, as in Andreas Johansson's example.
Case 3 If your application doesn't manage data, and all a save does is to save the state of the application, let the user choose with a setting whether there should be an autosave or not. If the user chooses to not have an autosave, still offer a restore-state function for when the application exited by a crash and not by the user closing it. Example: Firefox and saving the tabs from the last session.
Case 4 (hybrid) If you have something in the middle between case 1 and case 2, choose which method fits your specific case better. Example Wordpress: Wordpress will let the user create a mostly self-contained piece of information, like Case 1. It can also be serialized if needed, by exporting the resulting web page as a HTML file. But it actually works more like case 2, with the user input being persisted in a database and reused within the application instance only. In this case, there is no general recipe what to offer to the user, it depends on how much you will rely on the file metaphor.