Effective Java has a good example of the problems that inheritance can cause.

The example is: you have a List class. You want to instrument it to know how many items were ever added to the List. So it's not the same as size; it's at least as large as size.

The public API of the List class looks something like this:

class List {
  public add(Object item) { }
  public addAll(List items) { }
  public void remove(Object item { }
  public int size() { }
}

So say you use inheritance to instrument the class. Your solution looks something like this:

class CountingList extends List {
  public add(Object item) {
    ++numItemsAdded;
    super(item);
  }

  public addAll(List items) {
    numItemsAdded += items.size();
    super(items);
  }

  // no need to override remove, since it doesn't affect numItemsAdded

  public int getNumItemsAdded() {
    return numItemsAdded;
  }

  private int numItemsAdded = 0;
}

Seems reasonable. There's just one problem. I didn't show how addAll is implemented. It's implemented like this:

public addAll(List items) {
  for (Object item : items) {
    add(item);
  }
}

Whoops! It turns out that this double-counts items. The call tree looks like this:

CountingList.addAll (increases numItemsAdded by N)
  List.addAll
    CountingList.add (increases numItemsAdded by 1)
      List.add
    CountingList.add (increases numItemsAdded by 1)
      List.add
    CountingList.add (increases numItemsAdded by 1)
      List.add

Because of how polymorphism works, when the base class calls a base class method, it will actually call a subclass override if it exists. This is generally desirable. But to properly instrument the List class using inheritance, we need to know how it is implemented. We have to understand under what circumstances List.add will be called internally by List.

Consider instead composition:

class CountingList {
  public add(Object item) {
    ++numItemsAdded;
    list.add(item);
  }

  public addAll(List items) {
    numItemsAdded += items.size();
    list.addAll(items);
  }

  public remove(Object item) {
    list.remove(item);
  }

  public int getNumItemsAdded() {
    return numItemsAdded;
  }

  private int numItemsAdded = 0;
  private List list = new List();
}

Because there's no inheritance here, the call stack won't go back-and-forth between List and CountingList. The user will call a CountingList method, and that method will call a List method. Once it's inside List, it'll never call back into any CountingList methods.

The lesson here is that, with composition, you really only need to know the externally-visible API of a class. Inheritance deeply connect the base class to the subclass. Going back to the inheritance-based approach, we could work around the issue by not having addAll count any items. But suppose that List (which we didn't write) later changes its implementation. Maybe that future version of List.addAll doesn't need to call add at all. A reasonable change made to the implementation of List has broken our CountingList.

You might say "this is exactly what I meant by shared state!". But you could tweak this example to be completely stateless and the problems would persist.