Originally posted by: Lessi

As mentioned in the website, those both values should equal and most of the times I observed the same conclusion. 

https://www.ibm.com/support/knowledgecenter/SSSA5P_12.6.2/ilog.odms.cplex.help/refdotnetcplex/html/M_ILOG_CPLEX_Cplex_GetBestObjValue.htm

However, as you can see below, the log shows that getObjValue() returns 8, while getBestObjValue() returns 10 while I print those values. I am not sure  the reason why:

my piece of code :

                        cplexRestrictedM.solve();
                        solverStatus(cplexRestrictedM.getStatus());

                        cout << "cplexRestrictedM.getObjValue() = " << cplexRestrictedM.getObjValue() << endl;
                        cout << "cplexRestrictedM.getBestObjValue() = " << cplexRestrictedM.getBestObjValue() << endl;

and it shows (part of the logs); 

Tried aggregator 2 times.
MIP Presolve eliminated 4607 rows and 4423 columns.
MIP Presolve modified 152 coefficients.
Aggregator did 1 substitutions.
Reduced MIP has 110 rows, 89 columns, and 503 nonzeros.
Reduced MIP has 77 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.00 sec. (4.13 ticks)
Found incumbent of value 2.000000 after 0.01 sec. (7.47 ticks)
Probing time = 0.00 sec. (0.35 ticks)
Cover probing fixed 0 vars, tightened 2 bounds.
Tried aggregator 1 time.
MIP Presolve eliminated 1 rows and 1 columns.
MIP Presolve modified 41 coefficients.
Reduced MIP has 109 rows, 88 columns, and 492 nonzeros.
Reduced MIP has 76 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.00 sec. (0.39 ticks)
Probing time = 0.00 sec. (0.36 ticks)
Clique table members: 351.
MIP emphasis: balance optimality and feasibility.
MIP search method: traditional branch-and-cut.
Parallel mode: none, using 1 thread.
Root relaxation solution time = 0.00 sec. (0.27 ticks)

        Nodes                                         Cuts/
   Node  Left     Objective  IInf  Best Integer    Best Bound    ItCnt     Gap         Variable B NodeID Parent  Depth

*     0+    0                            2.0000       10.0000           400.00%
      0     0        9.4945    10        2.0000        9.4945       36  374.72%
*     0+    0                            5.0000        9.4945            89.89%
      0     0        9.0000    15        5.0000      Cuts: 19       51   80.00%
*     0+    0                            7.0000        9.0000            28.57%
      0     0        9.0000    12        7.0000      Cuts: 24       60   28.57%
      0     0        9.0000    10        7.0000      Cuts: 11       65   28.57%
      0     0        9.0000     6        7.0000   ZeroHalf: 4       66   28.57%
      0     0        9.0000    21        7.0000   ZeroHalf: 3       69   28.57%
*     0+    0                            8.0000        9.0000            12.50%
Repair heuristic found nothing.

Repeating presolve.
Tried aggregator 2 times.
MIP Presolve eliminated 41 rows and 31 columns.
MIP Presolve modified 94 coefficients.
Aggregator did 2 substitutions.
Reduced MIP has 66 rows, 55 columns, and 255 nonzeros.
Reduced MIP has 43 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.00 sec. (0.41 ticks)
Represolve time = 0.00 sec. (0.82 ticks)

Root node processing (before b&c):
  Real time             =    0.02 sec. (17.14 ticks)
Sequential b&c:
  Real time             =    0.00 sec. (0.00 ticks)
                          ------------
Total (root+branch&cut) =    0.02 sec. (17.14 ticks)
*****************************************
Optimal solution found
*****************************************

cplexRestrictedM.getObjValue() = 8
cplexRestrictedM.getBestObjValue() = 10 ////////////I expect 8 or at least 9 as the log shows
 

This indeed looks a but strange. What version of CPLEX do you use (the reference documentation you are pointing at is for 12.6.2)? Do you use any non-default parameter settings? Can you share the full log and/or the model for which this happens?

One reason for the odd behavior may be this

Repeating presolve.

It seems that CPLEX is able to perform a lot of fixings to your model during the root node and concludes that it is a good idea to repeat presolve with these fixings. Then repeated presolve immediately solves the problem. Since repeated presolve starts from scratch, it may re-start with the trivial dual bound of 10 and solve the model before it can install anything better.