SFDCWallah

Future Apex is used to run processes in a separate thread, at a later time when system resources become available.

Important Points about Future Method:

• Future methods must be static methods, and can only return a void type.
• The specified parameters must be primitive data types, arrays of primitive data types, or collections of primitive data types.
• Future methods can’t take standard or custom objects as arguments.
• Future methods can’t be used in Visualforce controllers in getter or setter methods nor in the constructor.
• You’re limited to 50 future calls per Apex invocation, and there’s an additional limit on the number of calls in a 24-hour period.
• You can’t call a future method from a future method. Nor can you invoke a trigger that calls a future method while running a future method.
• The getContent() and getContentAsPDF() methods can’t be used in methods with the future annotation.
• Can’t access the jod ID.
• A common pattern is to pass the method a List of record IDs that you want to process asynchronously.

The reason why objects can’t be passed as arguments to future methods is because the object can change between the time you call the method and the time that it actually executes. Remember, future methods are executed when system resources become available. In this case, the future method may have an old object value when it actually executes, which can cause all sorts of bad things to happen.

• Future methods are not guaranteed to execute in the same order as they are called.If you need this type of functionality then Queueable Apex might be a better solution.
• When using future methods, it’s also possible that two future methods could run concurrently, which could result in record locking and a nasty runtime error if the two methods were updating the same record.
• To make a Web service callout to an external service or API, you create an Apex class with a future method that is marked with (callout=true).
  public class SMSUtils {
  // Call async from triggers, etc, where callouts are not permitted.
  @future(callout=true)
  public static void sendSMSAsync(String fromNbr, String toNbr, String m) {
  String results = sendSMS(fromNbr, toNbr, m);
  System.debug(results);
  }
  }

Sample Future Method:

global class SomeClass {
@future
public static void someFutureMethod(List recordIds) {
List accounts = [Select Id, Name from Account Where Id IN :recordIds];
// process account records to do awesome stuff
}
}

Future methods are typically used for :

• Callouts to external Web services. If you are making callouts from a trigger or after performing a DML operation, you must use a future or queueable method. A callout in a trigger would hold the database connection open for the lifetime of the callout and that is a “no-no” in a multitenant environment.
• Operations you want to run in their own thread, when time permits such as some sort of resource-intensive calculation or processing of records.
• Isolating DML operations on different sObject types to prevent the mixed DML error.

Why we use future method to solve Mixed Dml Error: Mixed Dml Exception comes when we insert setup(like user object) and non setup(like Account object) in same transaction.
So future method runs in a separate thread so it solves are problem.One of the insertion we keep in future method to solve the exception.
This solution is like we solve multi threading problem in Java.

Best Practices for Future Method

• If using Web service callouts, try to bundle all callouts together from the same future method, rather than using a separate future method for each callout.
• Test that a trigger enqueuing the @future calls is able to handle a trigger collection of 200 records. This helps determine if delays may occur given the design at current and future volumes.
• Consider using Batch Apex instead of future methods to process large number of records asynchronously. This is more efficient than creating a future request for each record.
• To test future methods, enclose your test code between the startTest and stopTest test methods. The system collects all asynchronous calls made after the startTest. When stopTest is executed, all these collected asynchronous processes are then run synchronously. You can then assert that the asynchronous call operated properly.